DR for critical desktops in VMware View

VMware vSphere Infrastructure offer the highest levels of availability and responsiveness for applications and services, and to provide additional protection and deliver advanced capabilities for disaster recovery management VMware released vCenter Site Recovery Manager.

Whilst SRM provides disaster recovery management for the infrastructure, VMware View 4 does not have a native protection tool provided by VMware.

Interestingly I haven’t seen any documentation or white paper about protecting virtual desktops, other than the EMC blueprint called “EMC Business Continuity for VMware View”. The solution blueprint shows that there is a workable method for recovering VMware linked clone virtual desktops on the recovery site with custom scripts added to the SRM recovery steps.

I have to thank Jeff O’Connor (@cloudpimps) for putting me on the right direction.

It is possible to reconnect replicated (non linked clones) virtual desktops to a Replica Connection Broker in a DR environment. Some manual steps are required, which should be absolutely acceptable in most cases during a DR situation.

For this solution to work it’s assumed that your VMView environment is stretched between two distinct physical clusters located in different buildings (Primary and DR) in the same logical datacenter and managed by a single vCenter. The vCenter may be linked.

Regardless that in most cases virtual desktops will make use of linked clones I recommend not to use it for those few critical desktops, such as an executive pool of desktops holding your CEO and other members of the execute board, which need to be quickly recovered in a DR situation.


1 – Create two clusters in your logical datacenter, being the first one in your primary site and the second in your DR site. Normally each cluster would have the name of the building or location of the datacenter. Make sure your vCenter is hosted in the primary datacenter and use local SQL Express or a Clustered database solution.

2 – Deploy VMView Connection Server Standard in your primary cluster and the VMView Connection Server Replica server in your DR cluster. Make sure you enable the Replica Server to also work as broker. To do that, go to Configuration/Servers.

3 – Create a Desktop Pool without use of Linked Clone and deploy virtual desktops

4 – Setup the SAN replication, or use a solution such as vReplicator from VizionCore. The LUNS and/or Exports to be replicated should include the Virtual Desktops, your vCenter, User Profiles (Windows Folder Redirection), and templates to be able to generate new virtual desktops.

Recovery Process

1 – Break the SAN replication and mark datastores as read/write.

2 – Update DNS to reflect the new vCenter IP address (probably DR site will be in a different subnet)

3 – Register vCenter server in the DR cluster and update vCenter server with new IP address (probably DR site will be in a different subnet)

4 – Update DNS to reflect Connection Broker Replica (only if you don’t have a LB solution in place)

5 – Manually register replicated virtual machines (this can also be scripted using vmware-cmd -l register command).

Voila! The replica server now see all virtual desktops in the DR cluster and if you want the Desktop Pool to provision new virtual desktops, update the pool setting to point to the new cluster, resource pool and datastores. The failback process should work on the same way.

Important: Use only FQDN for resolution and have your DNS and AD published on your DR site.

For all other pools using linked clone technology I usually take them as non-critical and I leave an exact copy of the original pool pre-configured in the DR cluster. Something like “Pool001_DR”. In a DR situation, enable the pool and the virtual desktops will start to be provisioned. As you should also be replicating User Profiles, the impact should not be enormous.

If you couple the solution with an application virtualization product such as ThinApp your users would have all applications running exactly like they had before.

Off course this is not the most attractive solution, and I know I am presenting in a very raw format, but it should give you a direction on what to do to protect your organizations VMView environment against a possible catastrophe.

Update: The EMC paper can be downloaded from here



3 pings

    • Eugene on 06/18/2010 at 4:43 am

    Thinking about Cisco UCS and the fact that it can restore full server identity in DR site would you think the VMware View recovery would be much easier?

  1. @Eugene I don’t see how Cisco UCS will help you with a VMware View Recovery Plan. The UCS server identity is only applied to hardware components (blades). That means you are able to apply the same MAC addresses, WWPN, Firmware, BIOS version etc… Cisco UCS won’t help you with the IP configuration in a VM as an example. Additionally, today you can’t stretch the Cisco UCSM across WANS for DR across datacenters.

    Cisco OTV technology, on the other hand, can help you to stretch network across datacenters and facilitate the DR process. That will help in scenarios where virtual desktops use fixed IP addressing.

    • Eugene on 07/09/2010 at 4:09 am

    @Andre Leibovici The assumtion here is that L2 is common across sites, additionally, assuming you have full UCS stack in DR site matching primary – UCSM has seamless backup/recovery that can be scripted and injected into SRM as an extra step similar to SAN LUN mounts.

    Since you can install ESX as boot from SAN and SAN is replicated all your ESX servers (with exact the same identity) will be recovered in minutes. And because composed VDI desktops are tight together with the original ESX cluster there were provisioned on it should be seamless.

    Is this a valid idea?

  1. […] New VMware View parameters in your .vmx files January 21st, 2010 Andre Leibovici Leave a comment Go to comments Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.Powered by WP Greet Box WordPress PluginThe idea for this article started from a research that I was doing for creating a disaster recovery solution for critical virtual desktops in VMware View 4, without the use of Site Recovery manager (SRM) and also trying not to touch the ADAM database. I have published this article last week here. […]

    • New VMware View parameters in your .vmx files « Virtual Cloud on 01/21/2010 at 11:53 pm

    […] New VMware View parameters in your .vmx files January 21, 2010 Andre Leibovici The idea for this article started from a research that I was doing for creating a disaster recovery solution for critical virtual desktops in VMware View 4, without the use of Site Recovery manager (SRM) and also trying not to touch the ADAM database. I have published this article last week here. […]

  2. […] vLink1 vLink2 […]

Comments have been disabled.