*picture from VMware docs
Now then, everyone that has used VR knows that resizing VMDKs for replicated VMs isn’t the easiest thing to do.
But I have come across people who seem to believe that the only way to resize the VMDKs is via the CLI on a host….this is one of the options BUT IS NOT the only one.
Resizing via the CLI:
https://kb.vmware.com/s/article/2052883 > No need for me to repeat what it says, but you do it using vmkfstools. It works well but does require the person to have access to the host directly.
The key point when using vmkfstools , which isn’t totally clear in the kb is:
If the original size was 550GB and the new size at the Protected Site is 600GB you would run the following command at the command line on on the destination host at the DR site:
vmkfstools -X 600GB servername_1.vmdk
Recover the VM using VR:
- Fail-over the VM and VR will add the recovered VM to the inventory in a powered off state
- Stop replication
- Resize the VMDK on both VMs
- Remove the recovered VM from the inventory (DO NOT DELETE FROM DISK)
- Reconfigure replication and use the VM you removed from the inventory as a seed
You can use this whether you have used seeds previously or not and is my preferred method. There is a slightly different method that can be used for seeds if you want to have a gander here:
NOTE: When using VR with SRM, you would have to remove protection for the VM in SRM and then do the steps above. Then simply configure protection for it again in SRM. If you don’t remove protection for the VM in SRM, you will not be able to recover it using VR as SRM takes over control of the recovery of that VM and does not allow for a manual fail-over.
Everyone mentions the whole using the cli to do the VMDK resize, but no one mentions this way. I think this is easier and if you have different people who manage the replication/DR aspects of your environment, do you want other people having access to the hosts to do things? That’s a hell of a risk. 🙂