Continuing on from my previous post; Backup, Restore And Replicate App Volumes, AppStacks And Writable Volumes another large challenge I faced running a Global Enterprise VDI environment was managing the Golden Images.

The Challenge of Golden Image Replication

For those of you who might not be familiar with VDI environments, Golden Images are the virtual machines that virtual desktop pools are created from. If you need to add an application or make an OS customization for all of your end users, typically you will make the change in the Golden Image and then push that image out to the virtual desktops.

When a VDI environment consists of multiple sites, each separate site usually has its own instance of VMware Horizon or Citrix XenDesktop/XenApp. Each of these separate VDI instances will need their own Golden Images from which virtual desktop pools will be created. In an ideal world, being able to use the same Golden Images for all desktop pools regardless of which site they are in would make the most sense as typically the Pools are the same between sites and this will keep desktop images consistent for all end users. However, until now, this has proven difficult to achieve.

In legacy HCI environments, the replication of virtual machines is very difficult and painfully slow. The main two replication options we see being used are:

• vSphere Content Library – Using the built-in Content Library service, vCenters can be linked to provide the replication of Golden Images between vCenters
• Manual Export/Import – Using vCenter to export the Golden Images into an OVA/OVF template, manually copying them to the remote sites and then importing the template into vCenter

There are, however, downsides to both of these methods. In both cases, the whole Golden Image is being replicated each time an update is made. If an image is 60GB in size and there are three remote sites, that’s quite a lot of data that needs to be transferred, this usually is a very slow transfer process and can put a heavy strain on the WAN infrastructure. Additionally, when these images are copied between sites, the vSphere Snapshots are lost in the process making it very difficult to roll changes back if there are issues as all snapshot history is lost.

Golden Image Sprawl

Because of these replication challenges, what we end up seeing is Golden Image sprawl, configuration drift, and an inconsistent-user user experience. Each site has its own set of Golden Images, which are similar to the other sites, but over time the configuration of these images deviates from the other sites. These additional Golden Images also add operational overhead. Each image will need to be patched and kept up to date. The more images you have, the harder it is to keep track of them and the longer updates take to roll out.

Quick And Easy Replication using Datrium DVX

It shouldn’t be this painful. It doesn’t need to be this painful! Using Datrium DVX it only takes a few clicks to replicate Golden Images between multiple sites. The following video (5 minutes) is a brief demonstration of how simple it is to replicate a new snapshot on a Golden Image to a second site.

Some of the key benefits to understand are:

Deduplication and Compression – DVX uses the always-on global deduplication and compression service to only send the changes made to the Golden Image. Rather than sending the whole virtual machine, DVX will only send the data that has changed. This dramatically improves replication times and reduces the load on the WAN infrastructure.

Persistent vSphere Snapshots – When Golden Images are replicated between sites, so are vSphere snapshots. So each Golden Image will show the same snapshot history, regardless of the site they are in. This makes it a lot easier to rollback and forward changes.