vSphere Replication when using vRDMS

So you can use vRDMs with vSphere Replication:

https://blogs.vmware.com/vsphere/2015/07/vsphere-replication-virtual-rdm.html

There aren’t many use cases for it and it isn’t documented very well.

So I have just been pondering over something: vSphere replication supports VMs that have vRDMs but not pRDMs. ESXi5.5 now supports vRDMs up to 62TB. What it does, is it will bring the vRDM up as a VMDK file at the DR site.

I am throwing this out there as a possible option for replication of our VMs that have RDMs attached, since we have a few VMs that have RDMs attached to them and which need to be replicated too.

“If you wish to maintain the use of a virtual RDM at the target location, it is possible to create a virtual RDM at the target location using the same size LUN, unregister (not delete from disk) the virtual machine to which the virtual RDM is attached from the vCenter Server inventory, and then use that virtual RDM as a seed for replication. However, this process is a bit more cumbersome – especially compared to what we just discussed above.”

According this it is possible to use a “seed’ with vRDMs attached to it at the target site, so in theory we could ditch Array based replication all together.

I always thought that if you used vRDMS it just brought them up as a VMDK at the DR site but clearly I was wrong!

We did ponder over moving to large VMDKs as over 2TB is unsupported now but:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058287

You cannot hot-extend a virtual disk if the capacity after extending the disk is equal to or greater than 2 TB. Only offline extension of GPT-partitioned disks beyond 2 TB is possible.

We need to be able to extend these large disks on the fly, without downtime so that rules out large VMDKs.

Virtual Compatibility mode:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007021

To safely expand the RDM:

1.Expand the RDM LUN from the SAN side.
2.Perform rescan on the ESX and verify the new LUN size is observed.

Recreate the RDM mapping to update the mapped disk size using one of these methods:

3a. Utilise Storage vMotion to migrate the Virtual RDM disk’s pointer file (vSphere 4.0 and later).

Or

3b. Remove the RDM file from the Virtual Machine and delete from disk. Power off the virtual machine, note the scsiX:Y position of the RDM in VM Settings. Navigate to VM Settings > Add > Hard Disk > RDM, select the scsiX:Y position that the RDM was using before and then power on the virtual machine.

Perform a re-scan from the guest operating system.

I’ve tried all these methods and my conclusion is that a re-scan and Storage vMotion is the easiest and doesn’t involve any downtime.

You can then extend it in the OS and sVMotion it back to its original datastore

I attached a vRDM to my test VM, this stopped VR replication as it detected a new disk that needed to be configured.

• I dumped some random text files on the RDM in Microsoft Windows
• I then replicated the RDM volume via the SAN
• Killed the replication and attached that volume to the DR cluster
• I added the seed to the inventory and attached the replication vRDM to it using the same scsi ID
• I then reconfigured replication and it picked it the seed

It then did a full sync comparing the data.

Even if there is no data replicated a full sync can take an age to do, as it does a checksum compare for integrity. For the about 500GB it takes on average 2 hours per VMDK .

So for very large vRDMS, a sync even when using seeds could run into hours and hours. Also bare in mind when you resize the disks it will do a full sync again, as for any VR replicated VMs to expand the disk you have pause replication resize the disk at both ends and then and then restart replication. So this could leave you without protection for a long time.

This for me was a deal breaker really, but I kept on testing.

I then extended the vRDM at the Protected Site by 10GB, I did the re-scan and Storage vMotioned the VM  and it came up in the host.

I paused the replication and then did the resize at the DR site. I did it by manually adding the seed to the inventory and removing the vRDM from the VM at the DR site and adding it back in using the same SCSI ID (using option 3b from the list earlier), but when configuring it back up for replication I got a UUID mismatch, so I edited the VMDK file to match the source and then VR would re-sync.

KB on modifying UUIDs for seeds:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2041657

There is no documentation anywhere, about how to deal with resizing a vRDM that is protected by vSphere Replication, but I am assuming the way I did it is correct, or as close to being correct, haha.

With pRDMs it will give you a warning and let you configure up the rest of the VM but on completion it will say “A general system error occurred: No such device”.

I was hoping it would still replicate the rest of the VM and ignore the pRDM #sadtimes ha

Now this was more for experimentation on my end, so I could evaluate all options and see which worked best for me. As I have encountered my fair share of issues using the Dell Compellent SRA and vSphere Replication on the whole has been pretty flawless.