SRM

So that title is a mouthful, but I came across an issue for a customer today where network mappings within SRM were not functioning correctly when attempting to configure protection for virtual machines. To cover this off quickly, the environment is running vSphere 6.0U3 and SRM 6.1.2. The scenario was that we’d previously (a few months ago) configured all of the mappings in SRM (Network, resource, folder, etc). We then created a new protection group, and created a recovery plan for this particular protection group. This was back when the datastore actually had no virtual machines, so at that point in time there was no VM protections to action, as it was preparing for an upcoming project. ...

When setting up VMWare SRM 6.1 with array based replication, I was seeing an error after adding the array managers into SRM. The error was Duplicate initiator ‘iqn.1998-01.com.vmware:Server1-280206e1’ found in SRA’s ‘discoverDevices’ response. In the vmware-dr-xxx.log file found in C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs there was a tiny bit more info: 2016-01-13T09:39:10.757+11:00 [03508 info 'DrTask' opID=5cacf7dd] Task 'dr.storage.ReplicatedArrayPair.discoverDevices112' failed with error: (dr.storage.fault.DuplicateInitiator) { --> faultCause = (vmodl.MethodFault) null, --> command = "discoverDevices", --> responseXml = "<Initiator id="iqn.1998-01.com.vmware:Server1-280206e1" type="iSCSI"/>", --> id = "iqn.1998-01.com.vmware:Server1-280206e1", --> msg = "" } The error was being presented by the SRA, so it was something to do with the underlying storage configuration, rather than the host configuation. ...

I’m going through the process of installing VMWare Site Recovery Manager (SRM) 6.1 in our production environment, which is currently running vSphere 6.0U1. We use Nimble Storage arrays and have elected to make use of array based replication (ABR) for data replication between sites. During our initial testing and doing full failovers of some dev applications, I noticed that the datastore name within vCenter for the protected volume on the SAN was getting renamed, and had a prefix of snap-5b356a02-VolumeName ...