Dell EMC VMAX Instructions for use

NON-DISRUPTIVE MIGRATION : CONFIGURATION AND BEST PRACTICES TECHNICAL NOTES
VMAX NON-DISRUPTIVE MIGRATION
Configuration and Best Practices Technical Notes
ABSTRACT
Data migrations have always been challenging in an enterprise environment. The
complexity and size of very large storage environments makes planning for, scheduling,
and executing migrations extremely difficult. Migrations also often involve applications
that cannot be taken offline, even briefly for cutover to a new storage array. Dell EMC’s
VMAX Non-Disruptive Migration, or NDM, allows customers to perform online data
migrations that are simple as well as completely non-disruptive to the host and
application.
May, 2017

2
© 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries.
Other trademarks may be trademarks of their respective owners. Reference Number: H15464.2

3
TABLE OF CONTENTS
VMAX NON-DISRUPTIVE MIGRATION...............................................................................................1
EXECUTIVE SUMMARY......................................................................................................................5
AUDIENCE .........................................................................................................................................................................5
NON-DISRUPTIVE MIGRATION OVERVIEW......................................................................................5
NDM MIGRATION OPERATIONS........................................................................................................7
BENEFITS ..........................................................................................................................................................................7
MANIPULATION OF DEVICE IDS AND HOST PATHS.....................................................................................................7
SUPPORTED DISTANCE BETWEEN THE SOURCE AND TARGET..............................................................................8
EFFECTS ON DEVICES AND EXISTING REPLICATION SESSIONS.............................................................................8
BOOT FROM SAN SUPPORT...........................................................................................................................................9
RECOGNIZING THE NDM RDF GROUP ..........................................................................................................................9
SETTING UP MULTIPE NDM RELATIONSHIPS ..............................................................................................................9
HOW NDM HANDLES MASKING GROUPS AND VIEWS..............................................................................................10
RULES REGARDING MASKING GROUPS AND VIEWS...............................................................................................10
GENERAL CONSIDERATIONS AND LIMITATIONS.......................................................................................................11
SESSION LIMITS .............................................................................................................................................................11
HARDWARE AND SOFTWARE REQUIREMENTS.........................................................................................................11
CONFIGURATION REQUIREMENTS AND PREREQUISITES ......................................................................................11
SUPPORT MATRIX..........................................................................................................................................................12
PREFORMING NDM OPERATIONS USING SOLUTIONS ENABLER .............................................13
EXAMINE THE PRE-MIGRATION ENVIRONMENT........................................................................................................13
SET UP THE ENVIRONMENT.........................................................................................................................................15
VALIDATE AND CREATE MIGRATION SESSIONS.......................................................................................................16
PERFORM A HOST RESCAN .........................................................................................................................................19
CUTOVERREADY AND PASSTHROUGH MODE ..........................................................................................................19
LIST THE NDM SESSIONS .............................................................................................................................................21
EXAMINE THE DEVICE PAIRING AND IDENTITIES FOLLOWING A CREATE............................................................25
CANCEL A MIGRATION ..................................................................................................................................................28
PERFORM A CUTOVER TO THE TARGET ARRAY ......................................................................................................29
EXAMINE THE DEVICE IDENTITIES FOLLOWING A CUTOVER.................................................................................34
REVERT TO THE SOURCE ARRAY...............................................................................................................................35
COMMIT A MIGRATION ..................................................................................................................................................37
PERFORM A HOST RESCAN .........................................................................................................................................38
COMPARE THE PRE AND POST DEVICE IDENTITIES FOLLOWING A COMMIT ......................................................41
USE THE RECOVER COMMAND ...................................................................................................................................43
REMOVE THE MIGRATION ENVIRONMENT.................................................................................................................44
PRERFORMING NDM OPERATIONS USING UNISPHERE.............................................................45
EXAMINE THE MULTIPATHING CONFIGURATION......................................................................................................47
SET UP THE ENVIRONMENT.........................................................................................................................................47
CREATE MIGRATION SESSIONS ..................................................................................................................................49
PERFORM A HOST RESCAN .........................................................................................................................................53
CUTOVERREADY AND PASSTHROUGH MODE ..........................................................................................................53
VIEW MIGRATION SESSION DETAILS..........................................................................................................................54
EXAMINE THE DEVICE IDENTITIES FOLLOWING A CREATE....................................................................................55
CANCEL A MIGRATION ..................................................................................................................................................57
PERFORM A RESCAN FOLLOWING A CANCEL...........................................................................................................59
PERFORM A CUTOVER TO THE TARGET ARRAY ......................................................................................................59
EXAMINE THE DEVICE IDENTITIES FOLLOWING A CUTOVER.................................................................................64
REVERT TO THE SOURCE ARRAY...............................................................................................................................66
PERFORM A RESCAN FOLLOWING A CANCEL REVERT...........................................................................................68

4
COMMIT A MIGRATION ..................................................................................................................................................69
COMPARING THE PRE AND POST DEVICE IDENTITIES FOLLOWING A COMMIT..................................................71
USE THE RECOVER COMMAND ...................................................................................................................................74
REMOVE THE ENVIRONMENT ......................................................................................................................................76
ADD DISASTER RECOVERY TO THE TARGET ARRAY...............................................................................................77
APPENDIX A: HOST MULTIPATHING SOFTWARE NOTES AND SETTINGS................................79
AIX NATIVE MULTI-PATHING SOFTWARE ...................................................................................................................79
LINUX NATIVE MULTI-PATHING SOFTWARE (DEVICE MAPPER) .............................................................................79
POWERPATH (VERSION 5.7 AND ABOVE)...................................................................................................................79
POWERPATH WITH SOLARIS........................................................................................................................................79
WINDOWS 2012 WITH MPIO..........................................................................................................................................80
VERITAS DYNAMIC MULTI-PATHING............................................................................................................................80
ESXI WITH NATIVE MULTI-PATHING ............................................................................................................................80
APPENDIX B: AIX, GPFS, ORACLE RAC, POWERHA AND POWERPATH WITH NDM................80

5
EXECUTIVE SUMMARY
Data migrations have always been challenging in an enterprise environment. The complexity and size of very large storage
environments makes planning for, scheduling, and executing migrations extremely difficult. Migrations also often involve applications
that cannot be taken offline, even briefly for cutover to a new storage array. Dell EMC’s VMAX Non-Disruptive Migration, or NDM,
allows customers to perform online data migrations that are simple as well as completely non-disruptive to the host and application.
AUDIENCE
These Technical Notes are intended for:
Customers, including IT management and planners, storage architects, and administrators involved in evaluating, acquiring,
managing, operating, or designing and implementing VMAX3 or VMAX All Flash storage arrays.
EMC field personnel and partners involved in designing VMAX3 or VMAX All Flash solutions and planning for and
implementing migrations to VMAX3 or VMAX All Flash arrays.
Please ensure you are working off the latest version of this document as there are frequent updates made. The latest version can
always be found here:
https://www.emc.com/collateral/technical-documentation/h15464-vmax-non-disruptive-migration.pdf
NON-DISRUPTIVE MIGRATION OVERVIEW
Non-Disruptive Data Migration (NDM) is available for VMAX3 and VMAX All Flash storage arrays running HYPERMAX OS 5977 Q3
2016 Service Release or later and Solutions Enabler 8.3 or later. NDM is designed to help automate the process of migrating hosts and
applications to a new VMAX3 or VMAX All Flash array with no downtime.
Non-Disruptive Migration leverages VMAX SRDF replication technologies to move the application data to the new array. It also uses
VMAX auto-provisioning, in combination with PowerPath or a supported host multi-pathing solution, to manage host access to the data
during the migration process. Note - Migrations should take place during low IO activity to minimize Performance Impact.

6
Figure 1. NDM Overview

7
NDM MIGRATION OPERATIONS
The migration of an application from the source to the target array is completed using a sequence of user-initiated operations, each
which is fully automated. These migrations are performed at the Storage Group (SG) level. The entire migration of a storage group can
be accomplished with a few clicks in Unisphere or simple, short Solutions Enabler commands that perform the following five operations:
Environment Setup –Setup configures the migration environment that will be required to migrate any application from the
source array to the target array. It confirms that both the source and target arrays can support the NDM operations. This
includes ensuring that a useable replication pathway for data migration is available between the source and target arrays.
Once the Environment Setup has completed successfully, a Create operation can be run. The environment setup command is
run only once prior to the initial migration between two arrays. All other storage groups migrating between those arrays will use
the same migration environment.
Create –Solutions Enabler examines a specific application’s storage on the source array and automatically provisions
equivalent storage on the target array. The target devices are assigned the identity of the source devices and are configured
in a pass-through mode that allows the data to be accessed from both the source and target devices.
oAfter the create operation completes the administrator issues a host rescan to allow the host to discover the paths to
the newly created devices. After this is complete, I/O issued by the application will be directed to either the source or
the target arrays through the host multi-pathing software. HYPERMAX OS will ensure that all I/Os that are directed to
the target by the host are actually serviced by the source array until the cutover.
Cutover –A cutover operation moves the target devices out of pass-through mode, initiates data synchronization from the
source to the target and makes the paths to the source array inactive so that all I/Os are being serviced by the target array.
Commit –After the source to target data synchronization is complete and all application data has been migrated to the target
array, a commit operation is performed. During a commit operation, Solutions Enabler completes the migration by releasing
temporary resources allocated to perform the migration, permanently disabling access to the source devices, and assigning
the target device ID to the source devices.
Environment Remove –This is performed after all migrations have been completed to remove the migration environment. The
array to array connectivity configured for the data migration pathway is removed along with the rest of the infrastructure on
both arrays that was configured by HYPERMAX OS to support the migrations.
Other supported NDM operations
Cancel –Ends a migration that has not been committed. It removes storage provisioned for the migration on the target array,
releases resources allocated by Solutions Enabler to perform the migration, and places the source devices into the state they
were in before the Create operation was run.
Cancel with Revert - Run after a cutover operation to move the application’s data access back to the source array from the
target array and cancel the migration.
Recover –Attempts to complete a failed migration operation. Recover is run following a failure after the cause of the failure,
such as a connectivity issue, has been resolved.
Sync –Controls the replication from the target side devices to the source side devices after a cutover is done and all data has
been migrated to the target side.
List –Shows a list of migrations to or from a specified array, with the current status for each.
BENEFITS
Allows migration from VMAX to VMAX3 or VMAX All Flash with hosts and applications completely online
Designed for ease of use with control operations that automate the setup and configuration of the migration environment
Managed by familiar and simple user interfaces via Solutions Enabler and Unisphere for VMAX
Migrations can be easily cancelled and failed back to the source array for any reason prior to commit
MANIPULATION OF DEVICE IDS AND HOST PATHS
NDM is able to migrate data and cutover to the target array non-disruptively by both swapping device IDs between the source and
target devices and manipulating the paths from the host to both arrays. The device ID contains the device’s unique WWN and other
information about it, such as a device identifier that the user has assigned to a device through Solutions Enabler or Unisphere. All of
this information is copied to the target devices.

8
NDM performs the data migration and device ID swap without the host being aware. The path management changes appear as either
the addition of paths or the removal of paths to the existing source device. To the host and application, there is no change in the device
that it is accessing and access to the device is maintained throughout the entire migration process.
SUPPORTED DISTANCE BETWEEN THE SOURCE AND TARGET
NDM is supported across SRDF synchronous distance. However, because of the requirement that the host see both the source and
target storage, migrations will typically be performed between arrays within a data center.
EFFECTS ON DEVICES AND EXISTING REPLICATION SESSIONS
Devices that are included in migration session in both the source array can remain in existing replication sessions throughout the
migration. NDM will evaluate the states of any current replication sessions before proceeding with the migration and make sure that
they are in the proper state to allow the migration to succeed.
Though existing replication sessions can be left in place during the migration, replication relationships will not be migrated to the target
array. These replication resources will need to be created on the target array, if required, at the appropriate point in the migration.
For example, SRDF replication can be configured between the target array and its remote array while in the CutoverSyncing state or
after the CutoverSync state is reached. The new DR RDF pairs can then be allowed to synchronize before the Commit so that DR is
maintained throughout the migration. SRDF can also be setup in the CutoverNoSync state, which is reached when the sync command
is used to stop replication. For local Snap/VX sessions running against the source volumes, existing session on the source array can
continue as normal during the migration and new sessions can also be created at the same time that the new SRDF replication is
configured.
Storage on the source and target arrays that is involved in the migration of an application should never be altered, and the migration
resources should not be managed, outside of the NDM commands. If any changes in the migration session are detected when a
migration operation is executed, the operation will be blocked until the changes that were made are undone, allowing the migration
operation to proceed as expected.
SRDF Restrictions:
Migrating devices cannot be R2 devices.
Cannot be concurrent RDF devices.
The devices must not be enabled for RDF Consistency.
The R1 may not be part of an SRDF/Star configuration.
The RDF relationship may not be part of an SRDF/Metro configuration.
SRDF must not be replicating data from the target to the source, such as during an in-progress restore.
TimeFinder Restrictions:
The migration source or target may not be the target of a TimeFinder copy session.
SRDF must not be replicating data from a local replication operation, such as during an in-progress TimeFinder restore.
Open Replicator Restrictions:
The migration source device may not be the control device in an Open Replicator pull operation.
Open Replicator must not be replicating data from a remote device to a control device, such as during an in-progress restore.

9
BOOT FROM SAN SUPPORT
NDM supports hosts that boot directly from the VMAX. The host boot BIOS must be updated to point to the target volume so that when
the host is rebooted at a later date it will find the volume containing the operating system. For details on boot drive configuration please
refer to the vendor specific HBA management guide or BIOS guides.
Please refer to one of the Dell EMC’s host connectivity guides for more additional information regarding Boot from SAN configuration
guidelines.
RECOGNIZING THE NDM RDF GROUP
The RDF group created for NDM between two arrays can be identified by its label. The label follows the format of M_XXXXYYYY,
where ‘XXXX’ is the last four digits of the lower numbered VMAX and ‘YYYY’ is the last four digits of the higher numbered VMAX. This
group will be used for all NDM migrations between the two arrays.
In this example, the arrays are 000197800129 and 000195703184, making the NDM RDF group label M_01293184. Unisphere will
detect and use best available RDF ports for the NDM RDF group.
Note: The NDM RDF group should not be removed or relabeled. Doing either will cause NDM operations to fail.
Figure 2. NDM RDF Group
SETTING UP MULTIPE NDM RELATIONSHIPS
Multiple environment setup operations can be performed for a single source array, provided that a different target array is specified for
each migration environment. All NDM RDF groups on a source or target array can be in use simultaneously, for concurrent migrations
to, or from, an array.
For example, a single VMAX3 or All Flash target array can have multiple NDM RDF groups, each connected to one of four different
source VMAX arrays. This means that the VMAX3 array can be the target of migrations from each of those four VMAX arrays.
Likewise, a single VMAX source array can have multiple NDM RDF groups, each connected to one of four different target VMAX3 or All
Flash arrays. This means that the VMAX array can be the source of migrations to each of those four VMAX3 or All Flash arrays.
When migrations are completed, separate environment remove operations are required for each array pair. The environment remove
operation removes the NDM RDF group between the two arrays, provided that no devices on either array have an RDF mirror in the
NDM RDF group.

10
HOW NDM HANDLES MASKING GROUPS AND VIEWS
When NDM sessions are created, NDM configures storage groups (SGs), initiator groups (IGs), port groups (PGs), and masking views
(MVs) on the target array that exactly match the group names on the source array. Both initiator groups and port groups can exist in
multiple masking views, so these groups will be reused when applicable.
When the first SG on the first array is migrated to the target array, a SG will be created on the target with the same name that contains
the migration target devices, an IG will be created on the target with the same name that contains the host initiators, and a PG will be
created on the target based on which ports the host HBAs are logged into.
When an SG on the second source array is migrated to the target array, the SG name must be different. If necessary, the SG can be
renamed before it is migrated. The IG must have the same name because an initiator can only exist in one IG. If the PG on the second
array has the same name as the PG on the first array, then the PG built by NDM during the first migration will be reused. If it has a
different name, a new PG will be created with the same ports used in the PG created during the first migration.
NDM also supports migration of a Parent IG which has child IG’s.
RULES REGARDING MASKING GROUPS AND VIEWS
All migrations are performed against a Storage Group (SG), which is the data container that is migrated with NDM. The following rules
must be met:
Only SGs contained in masking views can be migrated. If the device is mapped to a port that it is not masked to for this SG, the
create operation will not be permitted.
A SG will not be able to be migrated using NDM if it contains devices that have been added to a second SG that belongs to a
masking view.
Multiple masking views on the SG using the same IG are not allowed unless PGs on the target array already exist for each view
and the ports in the PGs are selected to avoid duplicate host paths.
Only parent SGs and standalone SGs with masking views can be migrated. A child SG with a masking view on the child SG is not
supported.
If the SG is a parent, its child SGs will also be migrated.
Devices in the SG which are considered to be GKs (20 cylinders or less) will not be migrated to the target array.
Devices must not be masked to FCoE ports.
Devices must not be masked to iSCSI ports.
Devices must not be mapped to ports where the ACLX is not enabled.
There are restrictions on the entities that might already exist on the target array.
If a Storage Resource Pool (SRP) on the target array is specified for the migration, that SRP must already exist on the target array.
The names of the SGs (parent and children) that are being migrated must not exist on the target array.
The names of the masking views that are being migrated must not exist on the target array.
The names of the initiator groups that are being migrated may exist on the target array, provided that the groups on the target array
have the exact same initiators, child groups and port flags as the groups on the source array with the same names. Port flags that
are not supported on the VMAX3 are ignored. One exception to this is if the source IG was a parent IG that contained both group
names and initiators. With SE 8.4 on the target array, the IG will only need to have the same group names since when SE migrates
this IG; it will move all the initiators to a separate IG and will make it a child of the parent.