virtually_dazed
Contributor
Contributor

HP MSA 2040 iSCSI -- SRM fails on Recover and Reprotect operations.

Does anyone have any practical experience with the HP MSA 2040 iSCSI SAN, DL360p G8 servers running VMware 5.5 and SRM 5.8.  We have the HP MSA SRA 5.8.0.24 installed, and the MSA runs firmware GL200P002. We have deployed VMware 5.5 U1 in 2 sites on HP DL360p G8 servers direct connected TO MSA 2040 iSCSI SANs.  The intent is to use HP Remote Snap ARRAY enabled replication, with SRM 5.8 to manage the recovery and reprotect.  We've installed the hardware, networked the iSCSI, installed vmware, installed the SRM and SRA, configured the remote SANs and setup volume replication.  That all works as expected. When we run a test recovery, that is successful. When we run a real Recovery, we get error messages and find additional information in the sra log file that indicates an incomplete command, referencing unidentified initiators.  Volumes and VMs are left in a transient state and it is a mess to cleanup.  It appears the command.pl file in the installed sra version 5.8.0.24 does not properly detect that the volumes were Default mapped and builds the command using the Explicit mapping format.  That fails as there are no values for the referenced initiators.  We made a minor edit to the command.pl file to not include initiators, and that allowed the Recovery operation to complete successfully.  Reprotect fails miserably and we are past the range of being able to troubleshoot this further.  We've since switched to explicit mapping and reverted the command.pl file to remain 100% original.  Has anyone ever setup vmware SRM with MSA2040 array based replication and been successful with the Recovery and Reprotect operations.  Since the MSA2000 uses the same SRA, that configuration should be a valid comparable.  As a side note, we have setup vmware replication and can run recovery and reprotect successfully.  The 15 minute replication cycle is not acceptable for this particular application, so we need to figure out array replication. Any advice welcome.

0 Kudos
1 Reply
virtually_dazed
Contributor
Contributor

The solution turned out to be how the LUN was mapped.  After switching to Explicit mapping, the Recovery and Reprotect worked normally.

0 Kudos