Migrating data between systems non-disruptively

Both the management GUI and command-line interface support migrating volume data between systems non-disruptively. The non-disruptive system migration is a remote-copy relationship type that is dedicated to volume migration between systems.

With non-disruptive system migration, storage administrators can migrate volumes from one IBM Storage Virtualize system to another without any application downtime. This function supports a number of use cases. For example, you can use this function to balance the load between multiple systems or to update and decommission hardware. You can also migrate data between node-based systems and enclosure-based systems. Unlike replication remote-copy types, non-disruptive system migration does not require a Remote Mirroring license before you can configure a remote-copy relationship that is used for migration.

However, remote-copy relationships that are used for migration have the following restrictions:

Stop-with-access is prohibited. The volumes cannot act independently if they are using the same UUID.
Migration relationships cannot be added to a consistency group.
You cannot change the relationship to another type of remote-copy relationship.
Migration relationship cannot be converted into a 3-site relationship.
Associating change volumes to a migration relationship is prohibited.
Volumes in migration relationships cannot be resized until the migration is completed or canceled.
ODX must be disabled on both systems while migrating volumes.
Note: If ODX is disabled, it cannot be re-enabled on the 8.4.2 software. Currently ODX support is not available on 8.4.2.
Migration of volumes that are mapped to NVMe-attached hosts is not supported.
Migration of SAN-boot volumes is not supported.

Prerequisites

Before you can use non-disruptive system migration function, ensure that the following prerequisites are met:

Ensure that both systems are running 8.4.2 or later.
Create either a Fibre Channel or IP partnership between the two systems that you want to migrate volumes between. The maximum supported round-trip time (RTT) between the two systems is 3 milliseconds. Ensure that the partnership has sufficient bandwidth to support the write throughput for all the volume you are migrating. For more information, see mkfcpartnership command for creating Fibre Channel partnerships and mkippartnership command for creating IP partnerships.
Ensure any hosts that are mapped to volumes that you are migrating are correctly zoned to both systems. Hosts must appear in an online state on both systems. The system supports the following hosts and connection types for non-disruptive system migration:

Table 1. Supported hosts and connection types. Supported hosts and connections types for non-disruptive system migration.
Supported hosts	Connection types
VMware ESXi 6.x	iSCSI and Fibre Channel
VMware ESXi 7.x	iSCSI, iSER, and Fibre Channel
RHEL 7.x, RHEL 8.x	iSCSI and Fibre Channel
SLES 12.x, SLES 15.x	iSCSI and Fibre Channel
Solaris 10, Solaris 11	Fibre Channel
HP-UX 11iV3	Fibre Channel
AIX 7.3 TL1 or later	iSCSI and Fibre Channel

Using the management GUI

To create migration relationship, complete the following steps:

On the source system, select Volumes > Volumes. On the Volumes page, identify the volumes that you want to migrate and record of the volume name and capacity.
Note: If applicable, verify the storage tier that is being used to ensure that an appropriate tier is used at the target system.
On the target system, select Volumes > Volumes and select Create Volume. Create the target volume within the appropriate storage tier with the same capacity as the source volume.
To get Copy Services > Remote Copy option, you have to enable it by following Settings > Gui Preferences > Display Flash Copy Functions under Copy Services.
On the source system, select Copy Services > Remote Copy.
Select Independent Relationship.
Select Create Relationship.
On the Create Relationship page, select Non-disruptive System Migration.
Ensure that the auxiliary volume location specifies the system that you want to migrate to, select Next.
Select the Master and Auxiliary volumes to use in the relationship.
Note: Ensure that both the master and auxiliary volumes have the same capacity.
Select Yes to start the copy. Click Finish.
In the management GUI, select Copy Services > Remote Copy > Independent Relationship. Verify that the migration relationship that you created displays the Consistent Synchronized state.
Attention: Do not proceed until the relationship is in the Consistent Synchronized state.
Create host mappings to the auxiliary volumes on the remote system. Ensure that all auxiliary volumes are mapped to the same hosts that were previously mapped to the master volumes on the older system.
Ensure that the HBAs in all hosts that are mapped to the volume are rescanned to ensure that all new paths are detected to the auxiliary volumes. Record the current path states on any connected hosts. Identify the WWPNs used for the active and standby (ghost) paths.
Attention: Do not proceed if the additional standby paths are not visible on the host. Standby paths might be listed under a different name on the host, such as "ghost" paths. Data access can be impacted if all standby paths are not visible to the hosts when the direction is switched on the relationship.
In the management GUI, select Copy Services > Remote Copy > Independent Relationship. Right-click the migration relationship and select Switch Direction. This action reverses the copy direction of the relationship and switches the active and standby paths, which result in all host I/O being directed to the new volume.
Validate that all hosts are using the new paths to the volume by verifying that the paths previously reporting as standby (or ghost) are now reporting active. Verify that all previously active paths are now reporting standby (or ghost).
Validate that all hosts are using the target volume for I/O and verify that no issues exist.
On the original source system that was used in the migration, select the Hosts > Hosts. Right-click the hosts and select Unmap Volumes. Verify the number of volumes that are being unmapped and select Unmap.
On the original source system, select Volumes > Volumes. Right-click the volumes and select Delete. Verify the number of volumes that are being deleted and select Continue.
The volume migration process is complete.

Using the command-line interface (CLI)

To configure non-disruptive volume migration, enter the following commands:

On the source system, enter the following command to determine all the volumes that you want to migrate to the target system:
```
lsvdisk
```
In the results, record the name, ID, and capacity for each volume that you want to migrate to the target system.
On the target system, create volumes for each volume that you want to migrate, ensuring that you create the volume with the same capacity as the source volume. For example:
```
mkvolume -pool 0 -size 1000 -unit gb
```
On the source system, enter the following command to create a relationship for migration:
```
mkrcrelationship -master sourcevolume -aux targetvolume -cluster system2 -migration -name migrationrc
```
where sourcevolume is the name or ID of the master volume on the source system and targetvolume is the name or ID of the auxiliary volume that you created on the target system. The -migration flag indicates that the remote copy relationship can only be used to migrate data between the two systems defined in the partnership. Optionally you can specify a name with the -name parameter. In this example, migrationrc is the name of the relationship. If no name is specified, an identifier is assigned to the relationship.
On the source system, start the relationship by entering the following command:
```
startrcrelationship migrationrc
```
where migrationrc is the name of the relationship.
Note: The -clean flag cannot be used on migration relationships.
Verify that the state of the relationship is consistent_synchronized, by entering the following command:
```
lsrcrelationship migrationrc
```
where migrationrc is the name of the relationship. In the results that display, ensure that the state is consistent_synchronized.
Attention: Do not proceed until the relationship is in the consistent_synchronized state. Depending on the amount of data that is being migrated, the process can take some time.
After the relationship is in the consistent_synchronized state, create host mappings to the auxiliary volumes on the target system by entering the following command:
```
mkvdiskhostmap -host host1 targetvolume
```
where targetvolume is the name of the auxiliary volume on the target system. Ensure that all auxiliary volumes are mapped to the same hosts that were previously mapped to the master volumes on the source system.
On all hosts, ensure that the HBAs are mapped to the volume are rescanned to ensure that all new paths are detected to the auxiliary volumes. Record the current path states on any connected hosts. Identify the WWPNs used for the active and standby (ghost) paths.
Attention: Do not proceed if the additional standby paths are not visible on the host. Standby paths might be listed under a different name on the host, such as "ghost" paths. Data access can be impacted if all standby paths are not visible to the hosts when the direction is switched on the relationship.
Switch the direction of the relationship so the auxiliary volume on the target system becomes the primary source for host I/O operations be entering the following command:
```
switchrcrelationship -primary aux migrationrc
```
where migrationrc indicates the name of the relationship. This command reverses the copy direction of the relationship and switches the active and standby paths, which result in all host I/O being directed to the auxiliary volume.
Validate that all hosts are using the new paths to the volume by verifying that the paths previously reporting as standby (or ghost) are now reporting active. Verify that all previously active paths are now reporting standby (or ghost).
Validate that all hosts are using the target volume for I/O and verify there are no issues.
On the original source system, unmap hosts from the original volumes by entering this command:
```
rmvdiskhostmap -host host1 sourcevolume
```
where sourcevolume is the name of the original volume that was migrated.
On the original source system, delete the original source volumes by entering the following command.
```
rmvolume sourcevolume
```
where sourcevolume is the name of the original volume that was migrated.
The migration process is complete.