PowerPath Migration Enabler Cluster failover before commit results in needsRecovery(cleanup) status on migrations

PowerPath Migration Enabler Cluster failover before commit results in needsRecovery(cleanup) status on migrations

For example
==================================================================
Hnd Source Target Tech State
===== ========== ========= ============ ======================
c1 harddisk8 harddisk2 HostCopy(cl) needsRecovery(cleanup)
c2 harddisk9 harddisk3 HostCopy(cl) needsRecovery(cleanup)
c3 harddisk10 harddisk4 HostCopy(cl) needsRecovery(cleanup)
c4 harddisk11 harddisk5 HostCopy(cl) needsRecovery(cleanup)
c5 harddisk12 harddisk6 HostCopy(cl) needsRecovery(cleanup)

Attempts to issue a cleanup (with or without -force) results in the following error
C:\>powermig recover -handle c5
Recover migration for handle c5 ? [yes]/no:
PPME error(75): Cluster disk being migrated is not owned by this node

The source disk has been migrated to an alternate disk and all powermig commands require that the disks both source and target be resident on the node issuing the powermig commands.

Failback the resources to the node issuing the powermig commands.

There is no other solution to enable either resumption of the migration or cleanup of the migration. More than likely the migration will need to be cleaned up and the migration started from the beginning.

Note PowerPath Migration Enabler commands (powermig) have to be executed on the same node that the powermig setup command was executed with the source and target devices present, active and accessible on that node.

Query 1:  

Can removing the target LUNs from both cluster nodes could cause a change in the PPME state, allowing for an abort / cleanup without requiring the failback, Can this help to cancel the migration?

Answer>>: No , the kernel will still have a record stating that source is in migration which can not be updated outside of powemig right now.
 

Query 2: 

What happens with the "cleanup" operation and is there a manual procedure possible based on the "cleanup" code? 

Answer>>: Cleanup right now needs the state of the migration which resides in the UMD and that resides only on the MainNode (Node A). This is only accessible through the powermig command.
 

Query 3:

Is there any risk to having duplicate disk signatures because the migration from node A was in the sourceSelected state, before the cluster failover. So if we cancel the PPME migration manually, is there a risk that the Windows OS could see two different disks with the same disk signature, leading to cluster issues?

Answer>>:Yes , During sync the disk signatures are also copied to the target. The powermig cleanup on the original node will stop this issue from being present.
 

Query 4:

Could the current state (PPME on node A, cluster services on node B, node A rebooted after cluster failover) might cause any issues when Node B is eventually failed back to node A.

Answer>>: When Cluster fails back there should be no issues 
 

Query 5:

Would it make sense to remove the target LUNs from the two nodes, delete them, and then present new LUNs just to ensure there is no data on the target LUNs? So basically following the procedure below:
1. Remove registry entries and db*.* files from nodes A and B.

1. Remove target LUNs from both nodes.
2. Delete / recreate target LUNs and present back to both nodes.
3. Start PPME migration from node B (active node

Answer>>:Will not work , the driver will throw an error because the devices are already in migration and no one cleared its entry (i.e in memory entry ).
 

Query 6:

Will a reboot of the now passive node enable the cleanup on the new node

Answer>>:Only passive node i.e Node A reboot may not help , since all nodes have the awareness of migration via the Kernel mode driver and that has to be refreshed which can be done only via powermig run on the original node.