The following sections discuss upgrade issues that you must resolve when reverting to a Data ONTAP 6.5 family release:
If you created a flexible root volume in Data ONTAP 7.0 or later, you must convert it to a traditional root volume and destroy the FlexVol volume and any containing aggregate before reverting to an earlier release. For information about changing the root volume to a traditional volume, see the System Administration Guide.
Note
The reversion procedure will not allow you to proceed unless there is a traditional root volume on the system.
If you created and populated FlexVol volumes in Data ONTAP 7.0 or later, you must migrate the data to traditional volumes, and destroy the FlexVol volumes, any clones of FlexVol volumes, and any containing aggregates before you revert to an earlier release. For information about migrating data between volume types, see the Storage Management Guide.
Note
The reversion procedure will not allow you to proceed while there are FlexVol volumes, including clones, on the system.
If you created a FlexCache volume in Data ONTAP 7.0.1 or later, you must destroy it before reverting to an earlier release. For information about FlexCache volumes, see the Storage Management Guide.
If you have a storage system connected to DiskShelf14mk2 AT shelves with AT-FCX modules installed, you cannot revert the system to any release earlier than Data ONTAP 7.0.1. The shelves require Data ONTAP 7.0.1 or later to be run on the attached storage systems.
This reversion restriction applies to the following storage systems with DiskShelf14Mk2 AT shelves attached:
If you created user accounts in Data ONTAP 7.0 or later with groups, roles, and capabilities, their specific privilege levels will not be preserved if you revert to an earlier release. The user accounts and names will be preserved during the reversion, but each account will have full privileges in the earlier release.
The vol status command has been modified in the Data ONTAP 7.0 release family to distinguish between flexible and traditional volumes. If you created scripts for Data ONTAP 7.0 or later that rely on vol status command output, the scripts might not work when you revert to an earlier release. Specifically, the Status field in Data ONTAP 7.0 or later includes comma-separated entries that indicate volume type, but in earlier releases the entries are not comma-separated and do not contain volume type information.
Similarly, if you created scripts for Data ONTAP 7.0 or later that rely on aggr status command output, these scripts must be rewritten to support pre-7.0 vol status command output.
For more information about the vol status command and output, see the vol(1) man page.
If you installed and licensed the SecureAdmin product with an earlier Data ONTAP release, your existing SSL (Secure Socket Layer) protocol certificates are converted when you upgrade to Data ONTAP 7.0 or later and copies of the old certificates are preserved.
If you then revert to a release of Data ONTAP earlier than 7.0, you can continue to use the old SSL certificates as before; the new certificates are no longer valid after reversion. However, you must re-enable SSL after the reversion for the old certificates to take effect. For more information about SSL and SecureAdmin, see your SecureAdmin documentation.
Note
If you want to continue using SecureAdmin with SSL after reverting to an earlier Data ONTAP release, you must have the SecureAdmin product installed and licensed on your system. For more information about SecureAdmin, see the SecureAdmin Administrator's Guide.
Data ONTAP 6.5.1 introduced software-based disk ownership for clustered systems with DS14 or DS14Mk2 disk shelves attached and with SnapMover® licenses enabled. If you want to revert to a version of Data ONTAP earlier than 6.5.1 on a system where SnapMover vFiler migration is enabled and software-based disk ownership is assigned, you must ensure that the hardware-based ownership rules based on physical A loop and B loop connections are satisfied before reverting.
Attention
If hardware-based ownership rules are not satisfied, the storage systems might not be able to boot and their data might be unavailable after reverting.
To disable SnapMover vFiler migration and the software-based disk ownership that enables it, complete the following steps.
| 1 |
On one of the cluster nodes, enter the following command to ascertain whether or not the current software-based disk ownership assignments align with the cluster's A loop/B loop topology: aggr status -r ResultsIn the output of this command, all disks assigned to the current cluster node are listed as volume disks or as spare disks; all disks assigned to the cluster's partner are listed as partner disks. All disks on the same shelf must be assigned to the same cluster node and all disk shelf assignments must be consistent with the A loop B loop topology of the cluster. For example, in the CHAN column of the command output, all disks owned by the local storage system should have a CHAN value of FC:A and all partner disks should have a CHAN value of FC:B. |
|
| 2 |
If the aggr status command output indicates that disk ownership reflects the A loop B loop topology, go to Step 4. If the aggr status command output indicates that disk ownership deviates from the A loop B loop topology, you must change the disk assignments back to hardware-based ownership as directed in Step 3. |
|
| 3 | ||
|
The disk ownership deviates from the A loop B loop topology because you have migrated a vFiler unit with the vfiler migrate -m nocopy command... |
Change it back with the same command. Then go to Step 4. | |
|
The disk ownership deviates from the A loop B loop topology because you have split ownership of a single expansion disk shelf between the two cluster nodes... |
Use the disk assign command to assign all disks on the shelf to the cluster node attached to the shelf's A loop connection. Then go to Step 4. | |
|
The disk ownership deviates from the A loop B loop topology because you have reassigned a spare disk with the disk assign command... |
Change it back with the disk assign command. Then go to Step 4. | |
| 4 |
Disable clustering by entering the following command. cf disable |
|
| 5 |
On each cluster node, uninstall the license for SnapMover. license delete snapmover |
|
| 6 |
Reboot each cluster node, and when prompted, press Ctrl-C to display the boot menu options. |
|
| 7 |
On each cluster node, enter the choice for booting in maintenance mode. |
|
| 8 |
In maintenance mode on each cluster node, enter the following command: disk remove_ownership This command disables software-based disk ownership. Note |
|
| 9 |
Halt each cluster node to exit maintenance mode: halt |
|
| 10 |
Reboot each cluster node in normal mode. The system returns to ownership based on A loop and B loop connections. You can now safely revert the systems or enter the cf enable command to re-enable cluster operation. |
|
For more information about disabling SnapMover and disk assignments, see the MultiStore Management Guide. For more information about erasing software-based disk ownership, see the Storage Management Guide.
Reversion rules for software-based disk ownership apply to the following clustered storage systems with SnapMover and MultiStore licenses, and with DS14 or DS14Mk2 disk shelves attached:
These rules do not apply to clustered FAS270 and FAS 3000 series systems, which also include DS14Mk2 disk shelves and which must have software-based disk ownership enabled. FAS270 systems cannot be reverted to a version of Data ONTAP earlier than 6.5, and FAS3000 series systems cannot be reverted to a version of Data ONTAP earlier than 7.0.1.
SMB signing support was introduced in Data ONTAP 7.0.1. If any clients have been configured to require SMB signing (security signatures) and you revert your storage system to an earlier Data ONTAP release, the clients will refuse to connect to the storage system after reverting.
In addition, if your storage system authenticates with a Windows Domain Controller that requires SMB signing and you revert to an earlier Data ONTAP release, you cannot connect to the Domain Controller after reverting.
For more information about SMB signing, see the File Access and Protocols Management Guide.
LDAP signing support was introduced in Data ONTAP 7.0.1. If your storage system communicates with a Windows Domain Controller that requires LDAP signing and you revert to an earlier Data ONTAP release, you cannot connect to the Domain Controller after reverting.
For more information about LDAP signing, see the File Access and Protocols Management Guide.
Data ONTAP 6.5.3 and later releases correct a problem with storage system domain accounts, the Active Directory domain accounts created for your storage system. If you create a storage system domain account and then revert to a Data ONTAP release earlier than 6.5.3, you must run cifs setup after the reversion to recreate the storage system domain account.
Note
If you created a storage system domain account before upgrading to Data ONTAP 6.5.3 or later, it will continue to work after the upgrade, and it will also continue to work if you revert to an earlier release.
For more information about creating storage system domain accounts, see the Software Setup Guide for the Data ONTAP release to which you are reverting.
Copyright © 1994-2005, Network Appliance, Inc. All rights
reserved.
Part No. 210-01083_B0
File: 5revert5.htm
Last updated: 16-Dec-2005 18:19:19