VMware Cloud Community
virtually_dazed
Contributor
Contributor

Need help with using SRM with 2 sites with HP DL360p G8 servers and direct connected MSA 2040 iSCSI SAN

We have deployed VMware 5.5 U1 in 2 sites on HP DL360p G8 servers with direct connected MSA 2040 iSCSI SANs.  The intent is to use HP Remote Snap 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 the command.pl file in the installed vsa 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.

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, so that configuration should be a valid comparable.  As a side note, we 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.

Reply
0 Kudos
2 Replies
admin
Immortal
Immortal

If you don't get many responses here you may consider posting in the SRM community as well - Site Recovery Manager

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.

Reply
0 Kudos