Disclaimer: I am the Chief Solution Architect for Unidesk and an obvious Layering fan boy. I have done my best to present the differences between layering and how VMware Horizon Mirage operates, without turning it into an “us vs. them” type of write up. Hopefully you find it informative in spite of my admitted bias toward layering technology vs. others forms of desktop management.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Back in 2011, I ranted about Gabe’s use of the term “Layering” in my blog “What is this Layering you speak of?” My issue was calling profile tools or app virt products “layers” and confusing the market, since there was an emerging category of desktop management technologies called “Layering.” I then tried to explain what layering was:
Layering is a way to present to Windows a holistic C: drive that is made up of a number of distinct parts. At its simplest level “Layering” is file system and registry virtualization. The layers are stored in separate, isolated virtual disk files, but are presented to Windows as a single image.
Lately, I’ve been hearing the misconception that VMware Horizon Mirage is layering. The reality is that Mirage is not layering as most of us in the VDI business understand it. Yes, yes… I know their documentation says layering, layers, layer, and that is the messaging. But let’s compare Mirage to true Layering technologies..
Some of the better-known players in the Layering space include Unidesk, CloudVolumes, and even Citrix with their Personal vDisk (formerly Ringcube). All of these companies use layering to some extent with the goal of giving IT and end users the ultimate desktop: 1 gold image to patch, easy app packaging/delivery without the limitations and restrictions of app virtualization/isolation, major storage savings, and full persistence, including user-installed apps, etc.
CloudVolumes layers at both the App and Personalization levels. Unidesk layers the entire desktop - OS, Applications and Personalization, and Citrix leverages layering for personalization on top of their PVS or MCS products.
All of these companies essentially virtualize the registry and file system (using file system filter drivers and some form of registry virtualization) to create the magic of combining shared layers and unique personalization layers into a C: drive for a desktop, or group of desktops.
What is layering?
You can check out the original blog, but here are here are some of the basics of layering:
- Layers are containers for the file system objects and registry entries unique to that ”layer”. They can be the OS itelf, Apps or unique Personalization Layers.
- Layers are stored in virtual disks (or some container) that can be attached to a VM.
- Layers can be “shared” as read only. This is often used for Apps or Operating Systems to reduce storage footprint .
- Updating desktops with a new layer generally means just detaching the OLD layer (VMDK) and attaching the NEW layer (VMDK).
- Because of layering you can have layer sharing without the “loss of personalization on recompose” limitations of block-based systems like Citrix PVS or VMware View Composer.
- Layered applications look like they have been natively installed, even though they haven’t. Their file system objects and registry entries are presented to the desktop to give the appearance and functionality of a locally installed application.
- There is some method of virtualizing the file system and registry to create the magic of a single C: drive made up of these unique (isolated) layers.
Generally, a desktop using layers will have connections to multiple VMDKs (multiple layers). One or more of those VMDKs will be read-only (these are shared layers). Updating these layers is basically a swap VMDKs the VM is attached to. Each VM also will have a personalization layer that is read-write (in some cases this is even a non-persistent disk). This personalization layer is where changes that are unique to that desktop live. Swapping shared layers has no impact on personalization layers and should be a quick and relatively resource-lite process.
So what is VMware Horizon Mirage?
Mirage is essentially backup and restore technology cleverly applied to desktop management. Mirage is based on an agent system (Mirage Agent) that pulls updates from a central file repository (Mirage Server). Only, instead of remote executing an install (MSI) package like a traditional PC configuration management product, Mirage overwrites the files and registry entries that are already on the Windows desktop with the latest versions from the central repository.
Example: You create a “layer” for WinZIP and assign it to a desktop with Mirage. At the appointed time the Mirage agent will begin copying the files and registry settings from the server into the local Windows OS, adding entries and files as needed and overwriting any that already exist. If you then update the WinZIP package and assign the update to the desktop, Mirage will copy only the updates down and overwrite what needs to change.
It’s a cool approach. But there is no layering “magic” or merging of the file system, registry keys, separate VMDKs, etc. It’s simply a restore process. The only difference is that the “backup” came from a packager desktop with an identical OS, and the changes are being restored to one or more real desktops.
In layered environments each layer is isolated from everything else on the storage side, but it looks and acts and behaves like it’s installed, even though it’s not. In Mirage it is ‘installed’ as the files are copied to each and every desktop that the app or OS update is assigned to.
Below I outline some of the key differences I see between layering and the Mirage approach when it comes to VDI:
#1 VDI resource load during updates
Imagine the network, CPU, and I/O impact of an OS update with a service pack done the Mirage way, hitting 500 desktops at once. Basically it’s lots of file copies to large number of desktops simultaneously. This can work if you’re talking about 500 PCs with their own CPUs, excess processing power, and their own disk. But this is trouble in a VDI environment with shared resources.
This is why I believe VMware has continued to position Mirage as a physical PC management product, and has not encouraged the use of Mirage with VMware View yet. Trying to manage more than a handful of virtual desktops with Mirage would crush the server and storage with high CPU and high disk I/O - just like running any batch of restores would.
With a true layering product, updating a layer is just a disconnect of one VMDK and a reconnect of another, then blending whatever registry and file system changes are needed.. Connect a layer to a machine, merge and prioritize where needed, and “wha-la!” the app or OS update is there, with little impact on the VDI environment
#2 Handling Layer Conflicts
Another difference can be found in conflicts between IT-created layers. If you have separate Office product layers like Project, Office, and Visio, and are just copying files to targeted VMs, one layer can step on the other’s common files (MS Office licensing files and common directories come to mind). Conversely, layering technology allows for this issue and accommodates it by merging and setting proper layer priorities and dependencies.
Or my personal favorite… Drivers. Print drivers, USB device drivers, whatever. In Mirage, drivers, need to be in a specific OS or driver ‘layer’. This is because Mirage is replacing files/registry entries within the desktop (overwriting files and registry keys) and not merging the tricky things like the Windows driver store from different layers.
In Layering the File Systems and Registry are “Merged”. This is why layering companies use file system filters and registry virtualization. It allows “layers” that contain objects from different apps and OS’s to be merged LOGICALLY and presented to Windows as a C: drive.
#3 The upside-down layer stack – User doesn’t win
Another issue is that the Mirage layer “stack” is upside down logically.
The image on the left is Unidesk, the image in the middle is Mirage as advertised, and the image on the right is actually how Mirage stacks its “layers”:
Most LAYERING software will put the personalization layer above the apps and the OS. This allows for changes the user made to an app or OS to persist. The personalization layer is essentially on top of the “stack”. In the event of conflict the default behavior is that the personalization layer wins. The admin can override it, but the settings remain unless that happens.
In Mirage the OS is on top and wins by default. So if a user installs something (big selling point, User Installed Apps) that modifies a file or a registry entry, or a service that’s in the OS/App layer, they add a driver, or an Office plug-in, etc, and then the admin updates an IT controlled “layer”… the IT managed app or update can, and does, step on that user change by default.
Layering products can resolve conflicts in the user layer (lets say overriding something in the user layer) fairly easily. Because each app is its own layer the systems have the ability to not only prioritize layers, but also compare and remove objects from the personalization layer that conflict (negatively) with the IT created layer.
It should be noted here that not all conflicts are bad and need to be overridden by default. Actually the vast majority do not. If the personalization layer has a newer file in place of an older file presented in an IT layer, or if a user has customized a registry entry that started in an IT created layer, these are not necessarily BAD changes. An example of a “good” conflict can often be found in Microsoft Office plug-in or browser plug-ins. There may be a “conflict” but it’s not a negative conflict, just different than the original OS or app that was rolled out. Layering technology is meant to be able to sustain these changes by default or allow the IT staff to remove them depending on what type of conflict has occurred.
#4 No Storage Savings
Another byproduct of managing desktops the way Mirage does is that Mirage layers (since they aren’t layers) cannot be shared at the disk level. Oh sure, you can have an OS layer that you deploy to numerous desktops. But in Mirage it’s more analogous to a template in vCenter than it is an OS layer or gold image for a Linked Clone. In Mirage it deploys and manages a full copy of the OS and apps to each desktop VM.
VMware’s vision of how to fix this is for the customer to either:
- Run some type of inline storage dedupe to reduce disk consumption, or
- Deploy the desktops with Linked Clones so they start out sharing an image, (storage reduction) BUT, never update the master for the Linked Clones and instead run the Mirage agent inside the clones to update the desktops… Thus letting the redo logs, associated with each desktop, grow and grow.
Solution for the redo log growth? Some type of software-based compression/shrinkage of these transaction logs.
Layering technology on the other hand sees sharing of layers’ VMDKs as a key feature. It allows you to natively minimize the number of layer copies on storage (storage reduction), reduce the overhead by copying layers once for numerous desktops (low resource utilization on the hosts and desktops), never have to deal with performance-killing/space-eating redo logs, and allow for things like hybrid arrays to have smaller amounts of data to load into the SSD/Cache.
Layering as a technology is not easy. Actually, layering done right is REALLY hard. Handling conflicts, management, updates to layers, dealing with conflicting objects from the personalization layers, prioritization, and Windows specific stuff like driver store and fusion keys is down right tricky. BUT, it’s even harder with a product that uses functionality closer to a backup and restore product. It’s a fundamentally different approach to desktop management. That is why the layering companies have gone a different direction:
Separate virtual disks for each layer. Isolated from each other but with the ability to present as a merged C: drive. The management of stateless desktops with the persistence of full clone VMs.
Now, I’m not saying layering (or any software, vendor or technology for that matter) is problem free or doesn’t have limitations! I’m just looking at the fundamentals of the technologies and pointing out that it’s a real stretch to claim Mirage is layering when there are so many good examples of that technology available today.