Replication

I was recently involved in an issue in an evnironment that started out looking like a simple SSL certificate replacement and ended with multiple hours of troubleshooting with GSS and redeployment of vSphere Replication. Fun times, right?! Let’s take a step back. This customer has a straight forward environment. Two physical sites, one vCenter Server and external PSC per site (6.5) in the same single sign on domain. Each site had one vSphere replication appliance and one Site Recovery Manager Server, version 8.

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.

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