Best practice for doing a test recovery of a replicated VM

[jhardwood]

Certainly a newbie question:  We have a VM recently configured for VSphere replication, and it is replicating fine.  We would like, however, to test the recovery node on an isolated network.  What is the best practice for testing the recovery VM (in an isolated network while having the production VM continue to run), then resuming synchronization between the Production VM and the recovery VM?

[TedH256]

purchase and configure SRM? That is what it does ....

[jhardwood]

Hi Ted,

Thanks, but we are not that complicated to need SRM.  We have the infrastructure to replicate our few mission critical VMs and have configured vSphere replication to do so.  We just want to manually test one of the replicating VMs at the remote site on our isolated VMware test network, but I would like to understand the best practice for doing so. Is it as simple as:

Stop replication

Do a recovery of the replicated node to isolated network

Power down recovery node

Remove replicated node from VM inventory

Reactivate replication

Just a WAG on my end at the above, hence the desire to better understand the best approach.

Thanks,

jeff

[TedH256]

OK - I really am not trying to be rude, but ...

Replication is just replication - it is not recovery, so as with any replication technology there is no "best practice" for how to do manual recovery from a replicated dataset.

As for whether yours is a simple environment - well yes, really I think that SRM (especially when paired with vSphere replication) is a very affordable technology that scales to small environments perfectly. I have worked with several "small simple" companies who want to protect a few key assets and be able to demonstrate recovery capabilities.

I understand if you do not want it, I guess ... but having said that the "best practices" will be defined by the run-book that you develop.

Sorry I could not be more help - perhaps others have tried doing what you want to do?

[mmarinov]

The way of checking if everything is OK with your replication on the recovery site (it could be in the same VC) is:

- power down the source VM manually (With SRM you have this out of the box)

- Do manual recovery through the vSphere Web Client

- If you replicated between datacenters within the same VC you need to recover your VM in folder where it could be added in the inventory of the VC - there is a VC limitation that VMs with the same can't exist in the same virtual machine folder

- when the VM i recovered on the recovery site it will have its network disconnected (with SRM you have this out of the box with the network mappings) and you need to edit the recovered VM to fix this

- power on the recovered VM

Keep in mind that at this time there is no replication between the source and destination VM. In order to resume the things you need to:

- remove the recovered VM from the inventory (not delete it from the disk). Leave only the vmdk files and delete the rest files

- unconfigure the source VM replication and start the wizard for configure it again

- during this wizard point as destination folder the Vm of the recovered folder (the one that you left only the vmdk).

- now vSphere Replication will use the destination disks as inital copies and will continue the replication. Keep in mind that if the disks are large there will be delay before the start of sending deltas as VR needs to do some additional calculations between the source and destination disks

[jhardwood]

mmarinov,

Thanks SO much for this procedure. It is exactly what I was looking for to allow us to test.  One question:  Would it be possible to alter this procedure as follows to allow the source VM to stay up and running while testing the recovered VM?:

- "Pause" or "Stop" replication from VSphere replication Web Client.  Leave the source VM up and running

- Do manual recovery through the vSphere Web Client.

- If you replicated between datacenters within the same VC you need to recover your VM in folder where it could be added in the inventory of the VC - there is a VC limitation that VMs with the same can't exist in the same virtual machine folder

- when the VM i recovered on the recovery site it will have its network disconnected (with SRM you have this out of the box with the network mappings) and you need to edit the recovered VM to fix this

- power on the recovered VM on a test network, not the production network so as not to conflict with the still running source vm

Keep in mind that at this time there is no replication between the source and destination VM. In order to resume the things you need to:

- remove the recovered VM from the inventory (not delete it from the disk). Leave only the vmdk files and delete the rest files

- unconfigure the source VM replication and start the wizard for configure it again

- during this wizard point as destination folder the Vm of the recovered folder (the one that you left only the vmdk).

- now vSphere Replication will use the destination disks as inital copies and will continue the replication. Keep in mind that if the disks are large there will be delay before the start of sending deltas as VR needs to do some additional calculations between the source and destination disks

[mmarinov]

If you Stop replication - this effectively means that the destination files will be removed. So you don't want to do that

Pausing replication means that no changes are send to the target location.

Actually you can recover the VM w/o powering it off by choose the setting in the recovery wizard for not doing sync

Once the VM is recovered and added in the VC inventory it is a normal VM and you can connect it to what ever network you want. The network configuration is not part of the vSphere Replication product at all so you need to search for another mechanisms - manually through the UI or using PowerCLI or vCO

Hope this helps    

[Smoggy]

to understand the difference between "Pause" and "Stop" replication, we blogged this a while ago:

Stop vs Pause with vSphere Replication | VMware vSphere Blog - VMware Blogs

why this matters is that in the process mmarinov gave you one of the key pieces is to NOT remove the disks from the recovery site. If you did do that it means you would need to perform a full-sync or upload copies of the vmdks (if using the pre-seed technique) again.