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:

 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.
 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.

 License PPME using the PowerPath Licensing Tool.

 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.

 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.

 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.

 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.

 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.

 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.

 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

This completes the migration.