EMC PowerPath Migration Enabler - Host Copy (Windows)

Requirements:

• PowerPath, at least version 5.1 SP1 (I would suggest at least 5.3 if running Windows 2003/2008)
• PowerPath Migration Enabler key (host-copy)
• Supported storage array for target and destination

Details:

To explain this migration technique a little more, PPME is a block level migration.  It migrates the blocks on the LUN using the host to process the migration.  This can cause performance degradation depending on how active the host is and the throttle you specify during the synchronization. Since the migration is at the block level, whatever the filesystem/alignment offset on the source LUN is exactly what gets migrated. You can migrate to a larger LUN but NOT to a smaller LUN.
If you need to make a configuration change to the filesystem, such as correcting an alignment offset issue, PPME is NOT the tool.  EMC Open Migrator (OM), however, can do that. OM can migrate LUNs online, but the setup and takedown require reboots (no less than three). I digress, let's get on with the PPME migration.

Process:

The high-level process to complete a migration with PPME is this:

• powermig setup -src <pseduoname> -tgt <pseudoname> -techtype hostcopy
• powermig sync -handle <x>
• powermig query -handle <x>
• powermig throttle -handle <x> -throttlevalue <y>
• powermig selecttarget -handle <x>
• powermig commit -handle <x>
• powermig cleanup -handle <x>

Note: Adding -noprompt to many of these commands, specifically those that take action, prevent the yes/no prompt.

The detailed process to complete a migration with PPME is this:

1. Install PowerPath and/or PPME

   • Be sure to use a custom install and choose Migration Enabler as an option.  This is a default installation I use because it doesn't cost anything to install and does not interfere with any other functionality.

   • Supposedly you can install PPME after PowerPath without a reboot, but the few times I did that, I had to reboot. This would be the ONLY reboot during the entire process.

2. Prepare/present the target LUN.

   • Once the LUN is accessible to the host, this is all that is necessary. There is no need to prepare the filesystem or alignment offset.  In fact, whatever is done to the destination LUN will be overwritten by the storage migration.

3. License PPME using the PowerPath Licensing Tool.

4. Setup the migration session using the command:
        powermig setup -src <source_pseduoname> -tgt <target_pseudoname> -techtype hostcopy
   Where source_pseudoname is whatever PowerPath lists as the hosts LUN name.  For instance, harddisk1.  The same goes for target_pseudoname. This creates the relationship of the migration, using a session ID for all future tasks. Keep note of the session ID that is provided by PPME.

5. Next is to start the synchronization.  If there is going to be a negative performance impact for the migration, it will be during the synchronization.
        powermig sync -handle <x>
   Where <x> is the session ID. This starts the synchronization of the migration at a throttle level of 2 on a scale of 0-9.  0 is the fastest and 9 is the slowest.  I found that using 2 was acceptable for most of the migrations I completed. If I thought that was going to be be too aggressive, I set the throttle to a value of 5.  The migration takes longer to complete, but the IO contention was far less.
   At this point, data is copied from source to target while the read requests are serviced and the writes are mirrored to source and target.

6. Since the synchronization starts at a throttle of 2, there may be times when you need to slow it down or speed it up for whatever reason. This is NOT required, but if you need to the command is:
        powermig throttle -handle <x> -throttlevalue <y>
   Where <y> is a value from 0-9. Again, 0 is the fastest and 9 is the slowest.

7. To check the status of the migration, enter the command:
        powermig query -handle <x>
   The output will give you the percentage complete and give you an idea as to when the synchronization will be complete.

8. Once the status of the synchronization is listed as "sourceselected", it is time to finish the migration.  One thing to note, is that it is still possible to backout of this migration. Enter the following command to select the target LUN:
        powermig selecttarget -handle <x>
   At this point, the read requests are serviced by the target and the writes continue to be mirrored.

9. Now is the time to have the owner validate that the migration is acceptable.  If performance is not as expected, you can still backout of the migration by selecting the source (selectsource) and cleanup the migration as specified below, however that is not what we are after, is it?! If validation is successful, enter the following command to commit the change:
        powermig commit -handle <x>
   The reads and writes are solely serviced by the target LUN and the source LUN is no longer being used.

10. At this point, you can no longer backout the change.  The source LUN, however, is still presented to the host and the underlying filesystem is still valid. You have two choices on how to proceed:

    • Cleaning up the migration as documented by the PowerPath guide

      • This is destructive to the source LUN, as the guide says that it removes some data.  What that data contains is beyond me, but the end result is that the data on the LUN is not longer accessible by any host.
             powermig cleanup -handle <x>

    • My preferred option is to remove the LUN from host access and then forcing the session cleanup. That provides the ability to mount that LUN on a different host, or back to the original host if there was a need.  I would rename the LUN with the date of the migration and the name of the host. I would then leave that LUN bound for a week before destroying it, call me paranoid or over cautious.
           powermig cleanup -handle <x> -force

11. This completes the migration.