Virtual Desktop Backup Options for VMware View
Off and on I've received requests for help backing up virtual desktops created with VMware View. Along with these requests I usually get a question:
Why is it so hard?
Right now there is no seamless back-up method for VMware View. Nonetheless, the product has some real value. It is an asset for disaster recovery programs because it provides portability so desktops can be moved to the datacenter. How easily these virtual desktops can be backed up depends on how the virtual desktop infrastructure was created in VMware View. I'll explain the options and back-up approaches.
With VMware View you have two main methods for creating VDI sessions. One is to create the run-of-the-mill VMs that you're already used to. The second method is to create a linked clone, which is a snapshot of a virtual machine that shares virtual disks with the parent VM. Each method has its advantages and limitations.
VDI sessions from common VMs usually result in storage requirements and costs that are tough to swallow for virtual desktop environments of much size. However, this type of virtual desktop is easier to back up than a linked clone. If you have normal VM images that are static per user, you should be able to use your image-based backup tools that were designed for VMware from the ground up to back up these images. For restores, you might have do some work in VMware View to get the virtual machine back into the View inventory so the broker can hand out the VDI session again, but that shouldn't be a big deal.
Things start to get tricky when you look at linked clones. First, you need to understand that a linked clone is a snapshot with its own virtual hardware – which is different than a normal VM. With a virtual desktop population, you end up with a base disk that holds many, many snapshots, and each snapshot is a unique VDI session with its own IP address, name and numerous other details.
If you choose to use them, you can set up link clones one of two ways:
- As a static linked clone that saves the user settings and data on logout, or
- All changes are discarded on logout. If all changes are discarded on logout there isn't much reason to back up the linked clone. You'd only need to back up the base image, which you can do via the datastore browser by hand.
When you go to back up a linked clone, there are a few issues that come up with VMware and its API. To start, since the ESX host and Virtual Center are unaware of the linked clones, you can't use the vStorage API to back up these VMs. The second problem is that only VMware View knows the linked clone mapping, so trying to trace this back would require you to use an API from VMware View (if one exists), or dig into the VMware View database manually. Neither of these are good options from a back-up point of view. VMware needs integrate the linked clone data into Virtual Center and expand the vStorage API itself.
Those developments could come in the future, but what about backing up virtual desktops now? When using the vStorage API today to back up, it does a good job of putting an abstraction layer on top of the VM snapshot. This allows a back-up solution to grab blocks as if the snapshot didn't exist. However, on restore you lose the snapshot itself and end up with a monolithic disk, that from a data point of view is the most up to date, but has no snapshot on disk for you to re-attach. This works fine for VDI sessions that are NOT linked clones. However, VMware needs to expand the vStorage API to allow the snapshots themselves to be transferred, or allow the snapshot data be transferred back into an existing snapshot file, but vStorage API does not support these capabilities today.
So, for now if you have normal flat VMs with a static mapping you can back those up normally. But if you're using linked clones, the only real way to back up would be with hardware snapshots on LUNs that hold a small amount of VDI sessions.
Posted by Jason Mattox on 03/08/2011 at 1:16 PM