Upcoming updates to VMware Horizon Mirage mean it will finally be viable for VDI image management, but it remains to be seen how Mirage may affect View performance.
When VMware first purchased Wanova in May 2012, we looked to the Mirage single image management technology as a way to make managing nonpersistent virtual machines (VMs) easier, eliminating the need to recompose images and making it easier to manage the desktops that we deliver to users. However, Mirage didn't work well for VDI. For the past 18 months, we haven't seen any indication of VMware Horizon Mirage working outside of physical machines or one-off VMs in client hypervisors.
At VMworld 2013, that all changed. But before we get into the latest Mirage moves, let's look at why VMware Horizon Mirage didn't work well with VDI.
Storage impact killed Mirage mojo
Mirage was originally designed as a tool to manage physical desktops and laptops across LAN and WAN scenarios. It does this by breaking the OS up into individually manageable areas, like applications, user personality and OS. These separate areas, which VMware calls "layers" despite their inherent differences from what we generally consider to be layering, are crunched and optimized locally. Then, they're sent to a centralized server in a significantly smaller payload than imaging entire desktops. At boot, the Mirage agent applies a user's designated application and user personality information to the image, along with any admin-pushed updates.
It's great technology, and we've been fans of Mirage for some time. The problem is that it was designed to be used on one host, using lots of compute cycles and local IOPS to minimize the amount of data being sent across the WAN. On physical devices, this is great, but when you try to run this in VDI, it kills the host density beyond using one or two machines because there is so much additional impact on storage and CPU, multiplied by all the machines on a host.
We learned at VMworld that Mirage is being modified to work in VDI environments. There are two upcoming releases: The first (due in 2013) will support persistent VDI environments (which VMware calls full clones) in VMware Horizon View. The second will add support for nonpersistent desktops and is due out in Q1 or Q2 of 2014.
How will Mirage affect View?
More on VMware Horizon Mirage
VMworld ditches Horizon updates
View gets folded into VMware Horizon Suite
There are a few things that remain to be seen. The first is how Mirage will affect View environments. The technology uses so much CPU and storage performance that you can expect either some impact on VDI density or on Mirage performance and functionality. It could be that the Mirage used in VDI is different from the Mirage used on physical machines, but we'll have to wait and see.
The second issue is that some people in the industry hope for Mirage to replace or at least provide an alternative to current image management techniques. Rather than using linked clones to build nonpersistent machines, you could envision a situation where you use Mirage to add both applications and personality to VDI VMs and eliminate the need to rely on linked clones. This would, at least in theory, eliminate the need to recompose VMs to reconcile storage consumed by user data disks because Mirage offers a level of deduplication/single instance storage.
If the forthcoming versions of Mirage do address VDI image management and composition, then I expect to see an uptick in the adoption of nonpersistent VDI among View customers. Either way, it's good to finally see some movement on the Mirage front. I'm anxious to learn how organizations will use the technology now that we'll actually get a chance to see it in VDI environments.
This was first published in September 2013