Storage

Introduction Nimble Storage arrays are one of my favourite SAN arrays to work with at the moment. However, until Nimble OS3 which was made GA on the 31st of August, 2016, there was no support for the XCOPY VAAI primitive. This meant that when performing actions such as a storage vMotion that moved data between datastores on the same array, or cloning virtual machines, the ESXi host performing the action was required to read the data from the array up through the ESXi host, and then write it back to the array, creating additional load on the ESXi host and traffic on the storage adapters and network.

So last week I noticed that a user by the name of Dean had opened a thread on the Nimble Connect forums with some handy PowerCLI to configure an ESXi host to connect to Nimble Storage arrays. I had done the same thing near the end of 2015 when we installed 6 Nimble Storage arrays in our environment, and I was meant to get around to putting it all together in a powershell function/script.

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