DR Testing When Source VM Powered On

[cfsullivan]

I am just beginning to look into vSphere Replication as a DR solution for a few servers.  We need to be able to test recovery of these VMs in our DR drills.  All of our hosts are controlled by one vCenter server and one of the hosts is attached to an isolated subnet where we can recover VMs for DR testing.  The same host can be attached to the production subnets for a real DR scenario.

The problem seems to be that if I were to go with vSphere Replication as a solution I may not be able to test it in our environment, according to what I read in this guide:         

http://www.vmware.com/files/pdf/techpaper/Introduction-to-vSphere-Replication.pdf        

It says: "The replica cannot be powered on and recovered if the original virtual machine is still reachable and is itself still

powered on. To continue, the primary copy of the virtual machine must be unreachable by vCenter Server or

powered off."

Unless I am misunderstanding this, because the vCenter server will be aware of the prod VM as well as the target, it will not allow me to start up the target (DR VM) for testing.  If this is true, how are other people testing recoveries?

Thanks.

[mvalkanov]

Hi,

Please see the following topic in the official docs -  http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.replication_admin.doc/GUID-94162EDE-155F-4481-9DB0-F580FCF743FB.html

There is option (checkbox in the UI) to not replicate the latest changes from the source site. So even, if the source VM is still powered on, only warning is displayed and recovery wizard allows you to continue.

This option is also present in VR 5.1.0.1 and VR 5.1.1. Perhaps the guide referenced above missed to mention it.

If using SRM on top of VR, test failover and test cleanup are standard operations for Recovery Plans.

If using VR without SRM, currently there is no explicit test failover/test cleanup, but in order to test, you would need to:

1. Perform recovery.

2. Stop the replication - to remove it from the VR UI.

3. Verify that the recovered VM is ok.

4. Power off the recovered VM and unregister it from the target vCenter Server inventory, but keep the disks.

5. Configure replication again and point it to the already existing disks at the target datastores. These will be used as initial copies and only the changed blocks will be transferred. Checksum will be computed to find the initial differences between the disks.

Regards,

Martin

[cfsullivan]

Thanks, that helps a lot.  I'll go ahead with the evaluation and let you know how it works out.

[smitchuson]

I almost had this same question and didn't even realize it.  Thanks for posting that info!

[cfsullivan]

I finally got around to testing this and it worked like a charm, so thanks Martin.  I recovered a couple of test VMs, one of which was recovered to an isolated subnet while the source VM was still running.  After confirming the integrity of the target I was able to use its VMDKs to seed a new replication of the same source VM.  The entire experience from setting up the appliance to recovering VMs was very simple.

I am wondering about one thing that has to do with the disks that I am reusing to do the seeding, if someone knows the answer:  Is the replication a true mirror?  In other words, will any changes made to the data on the VMDKs while they were on the recovered VM be wiped out?  I would think so and hope so, but I don't want to assume this.

Cheers.

[Biliana Petrova]

Yes, when you use seeds, vSphere Replication will compare source and target vmdks and will replicate the changed blocks. That means that seed files will be overwritten.

[cfsullivan]

Thanks for confirming that.