Why VMware Mirage is NOT the same as virtual desktop layering - Ron Oglesby - BrianMadden.com
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.

Why VMware Mirage is NOT the same as virtual desktop layering

Written on Sep 12 2013 16,111 views, 7 comments


by Ron Oglesby

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.

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.


Click to enlarge

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”:


Click to enlarge

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:

 

  1. Run some type of inline storage dedupe to reduce disk consumption, or
  2. 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.

Wrapping up

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. 

 
 




Our Books


Comments

Daniel Bolton wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Thu, Sep 12 2013 3:31 AM Link To This Comment

I think its fair to say.. Layering Vs Agent based, at this moment in time, is very much VM Vs Physical (minus some exceptions)?

I think they are both great approaches and it's starting to sounds like an old saying now... all boils down to "use case"..

Great write up (clicking on the image didn't make it larger :-/)!

Ron Oglesby wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Thu, Sep 12 2013 10:06 AM Link To This Comment

I hope App Detective is floating around. He requested this (and may note my disclaimer at the start... good advice :-)

appdetective wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Thu, Sep 12 2013 5:12 PM Link To This Comment

@Ron, good balanced post and I hope many people read it. Also the upside down point was eye opening for me.

I just don't see adoption of Mirage in the datacenter by enterprise customers as it lacks capability vs. true layers. Most just want to do persistent desktops anyway and stay as they are.

I'd love to see VMware's response to this.

MaDDo wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Wed, Sep 18 2013 10:53 AM Link To This Comment

@Ron, good post to explain what UniDesk does, a little less on what VMware Mirage does. In my opinion you are focussing to much on technology and terminology and missed the chance to describe the use-cases.

I agree, VMware is using the term Layering where in my opinion the should be calling it something else to prevent confusion. But hey; the whole world is using the word "cloud" in a way it shouldn't be used; it's a war you can't win.

And I'm honest; I know better what Mirage does then what UniDesk does but I think the main difference is; UniDesk is a solution made for Application Delivery/Management in VDI and VMware Mirage is made for full (remote) fat client management, those are two completely different use-cases.

And comparing those two as they are equal is kind of useless in my opinion.

Sure, I also assume VMware bought the Mirage with the idea of using it in VDI for app-delivery and that hasn't worked out the way the hoped, but that doesn't mean that the technology is useless as a whole.

So don't get me wrong; I appreciate your effort for making people understand the difference between the technologies, but it would have been more comprehensive if you attached use-cases to it. I'm afraid to this point people still don't have a clue when to use which solution.

appdetective wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Wed, Sep 18 2013 11:49 AM Link To This Comment

@maddo VMware has said many times that they are going to make Mirage work on VDI. So Ron is right in pointing out why they are likely to fail trying to do so.

Ron Oglesby wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Wed, Sep 18 2013 10:30 PM Link To This Comment

@MaDDo

App D is right. This is the result of VMware EUC announcements (not real code in the field yet) at VMworld abour how "Layering is coming to VDI! and its Mirage"

While I completely agree that the two technologies are different animals, I find it funny that until right about the time of the purchase Wanova did not call their tech "Layering". And for 4 years VMW EUC has crapped all over layering and held up Linked Clones and thinapp as all you needed.

Now... they have a different story.

I believe they bought Mirage for physical management. But since they can't really crack the physical market (its a tough place to compete) they need to do something with it. And why not beat Citrix up with a Layering message we have had in the VDI market for 4 years.

sachinsharma wrote re: Why VMware Mirage is NOT the same as virtual desktop layering
on Thu, Oct 10 2013 5:59 PM Link To This Comment

We've just recently published a blog post that answers many of the issues raised here with regards to layering in Mirage. Take a look: blogs.vmware.com/.../vmware-horizon-mirage-layering-explained.html

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.