How to move an iSCSI Storage Virtual Machine (SVM) or volumes
Applies to
- ONTAP 9
- iSCSI
Answer
- The migration of an iSCSI Storage Virtual Machine (SVM) or volumes within NetApp's ONTAP system is a process typically carried out using ONTAP's management interface or Command Line Interface (CLI).
- This procedure is independent of the host OS, such as Linux or Windows, and is performed through the ONTAP system operations.
- However, host-side configuration changes or rescans may be required.
- Here are the general steps for moving iSCSI SVMs and volumes on the ONTAP system:
- Moving SVM:
- The migration of an SVM usually involves the use of the SVM DR (Disaster Recovery) feature.
- Setting up SVM DR allows replication of the data and configuration of a specific SVM to another cluster or a different node within the same cluster.
- When moving an SVM, it's necessary to appropriately move or reconfigure the associated Logical Interfaces (LIFs).
- ISCI volumes can be migrated using volume snapmirror as well.
- Moving Volumes:
- Volumes are moved using the '
vol move' command. - This command is executed on the ONTAP system and asynchronously moves the volume to a different aggregate within the same SVM.
- The volume remains online during the move, allowing continuous data access.
- For Windows iSCSI hosts, the steps are as follows:
- iSCSI Initiator Configuration:
Open the iSCSI Initiator on the Windows machine and ensure the current iSCSI targets and sessions are correctly configured.
- Pre-Migration Preparation:
It is recommended to stop applications and services to maintain data integrity before proceeding with the migration.
- Volume Movement in ONTAP:
Perform the volume movement on the ONTAP system (as per the steps mentioned above).
- Rescan in Windows:
After moving the volume, execute 'Re-Scan Disks' in the Windows iSCSI Initiator to recognize the changes.
- Resuming Applications:
Once the move is complete and Windows can access the iSCSI target through the new path, restart the applications and services.
- Impact on Users During iSCSI Volume Migration:
- LUN Mapping:
While the LUN mapping is usually maintained during volume movement, moving SVMs or LIFs may require reconnection on the host side.
- LUN Recognition:
If the host does not recognize the new path after the move, the LUN may become invisible. This can be resolved by rescanning or updating settings on the host side.
- User Communication Disruption:
Although volume movement is typically non-disruptive, moving SVMs or LIFs can lead to temporary connection loss.
- Write Inaccessibility:
While ONTAP is designed to continue data access during volume movement, temporary disconnections can prevent data writing during that period.
- NOTE:
It is crucial to carefully plan the migration work, validate in a test environment beforehand, and consider performing the actual migration during maintenance windows.
Additional Information
- LUNs contained in mirror destination volumes can be mapped to initiator groups (igroups) and connected to clients.
- However, the client must be able to support connection to a read-only LUN.
- SVM DR supports replication of iSCSI and FC LUNs and NVMe namespaces hosted on replicated volumes.
- SAN configuration information (initiator IDs, LUN IDs, igroups or SAN LIFs) are not replicated as part of the replicated SVM configuration data set.
- Additional configuration on the destination cluster, and potentially on clients accessing the namespaces or LUNs, is required.
SnapMirror configuration and best practices guide for ONTAP 9 ( page 64, 23 )
- Many SAN clients cannot access a LUN that resides in a read-only container, such as a SnapMirror destination volume. Generally, LUNs should be mapped to igroups and mounted by SAN clients after the SnapMirror break operation is performed.
- SnapMirror configuration and best practices guide for ONTAP 9 ( page 80)