Disaster recovery across datacenters

[Uniq]

Hi,

We want to implement disaster recovery across datacenters. One datacenter will have an active VMware View implementation, the other datacenter has to have the VMware implementation ready to be active in case of a disaster in the first datacenter.

My question is: does VMware View work with VMware SRM?

If yes, what are the actions which needs to be done to implement this solution?

I can't find any information on the internet about this.

So if anyone has some information about this please let me know.

Thanks!

merl

[jguzmanr]

I asked these very questions to vmware during our POC with View. Their response was they hadn't tested it, but it probably wouldn't work as some manual intervention would be needed.

[Uniq]

Well, VMware and EMC did a presentation together at VMworld 2009 europe about this subject, so it should work (together with some scripting).

I have contact with VMware and have sent them my questions concerning this subject.

[depping]

it's not supported by default. I know indeed VMware and EMC did a presentation indeed during VMworld and they managed to get things working. You might want to see if you can get a hold of these. I know one of my colleagues within PSO is also doing a project at the moment combining View and SRM, but I can't unfortunately give more details at this point in time.

Duncan

VMware Communities User Moderator

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".

[Uniq]

Well, because the composer is on the VC and the VC can't failover when using SRM because the VC's on both site are used to do a failover, the composer is the main problem for View to be used with SRM.

Because of that, there has to be a View implementation on the primary site and also a seperate View implementation on the DR site.

What if we don't use the composer.

In theory you can then failover the whole View infrastructure to the DR site.

The VC configured in View and desktop pool is however not in the failover.

How does View have to be configured for this?:

Does both VC have to be configured in View and after a failover connections to the desktops can be made because View has the VC of the DR site configured?

Or is the VC availability not needed for connections to the existing desktops to be made?

[Uniq]

My guess is that the connections to the existing desktops can be made when the VC configured in the desktop pool isn't available after a failover.

However a new user can't get a new desktop.

For this a new desktop pool has te be made on the DR site, configured with the VC of the DR site.

How can a failback be done in this case? the desktop which failed over can be used again, and also this desktop pool for new users can be used again because the VC on the primary site is available again. But what about the new desktop pool made on the DR site?

[IanGibbs]

The crucial thing is that if the CS discovers the VM as missing it will then search the inventory on that VC for it. If it doesn't find it, it will remove the VM from the desktop rendering the desktop useless. You'd have to synch the VC contents, the Composer contents, the broker contents, use the same VC DNS name, etc. You might pull something off if the VC and the composer are virtual and also get failed over.

Much easier would be to maintain a separate View installation and VC on the secondary site, and synchronise the Desktop set up between the two (without them actually being a pair). The secondary site would have the config but not the VMs (provisioning disabled). Then when there was a disaster just enable the provisioning and View Composer will do it all for you. New VMs for each user of course, but if you have maximised the portability of your users it won't be an issue (better than not working at all).

[Uniq]

Well, we are probably not going to use the composer service because the users are allowed to install applications. When we use the solution you mention (presentation VMworld 2009), their self installed applications are gone if they get a new linked clone on the DR site.

Even when you attach the replicated UDD to the new linked clone, they still won't have their self installed applications back.

So linked clones are not an option, full clones are.

The VC and composer can't failover when using SRM, because the VC is managing the SRM failover.

You mean that if the virtual environment goes down (esx hosts and the VC), the connection server will remove the desktops from the pool by itself? Now that would be strange behaviour when the desktops are persistent.

[IanGibbs]

Err, not quite. I mean there is a clean up process whereby if you have deleted the VM from VI instead of removing it through the broker, the broker will remove its entry for the VM (effectively forgetting about it). If VC was down it wouldn't be able to verify that the VM had gone, so it would leave the entry there. I'm saying if you connected the broker to a different VC pretending to be the first one that didn't have the VMs in the same places, the broker would clean-up for you.

[Uniq]

So View checks periodically if the VM's still exist?

[IanGibbs]

It does. If it find they are missing, it does a search for the VM name (in case you renamed the folder it is in or the datacenter). If it then still can't find it, it deletes its entry.

[Uniq]

Thanks for the info!

[Uniq]

I have made a script which changes the VMware View database.

It changes different values, like vm id, vcenter server, site name, cluster name etc.

The script works great with VMware SRM