Managing Horizon View Desktops with Horizon Mirage: Supported scenarios

With the latest release of Horizon Mirage (4.3) VMware introduced the ability to manage Horizon View Desktops using Mirage. While the supported scenarios are currently somewhat limited it is still a major benefit when you have to manage full clone persistent desktop.

Support for managing virtual desktops with Mirage is currently limited to the following scenarios:

  • The virtual desktop needs to be deployed using VMware Horizon View 5.3
  • The virtual desktop needs to be deployed as full clone persistent desktop

Also currently only the following Mirage operations are officially supported with full clone persistent desktops:

  • App layer management
  • Base layer management
  • Enforce layers (to enforce IT applications and settings)
  • Apply driver library

Even with all these restrictions in mind you now have the ability to manage your virtual persistent desktops and your physical desktop with the same tool and the same image (Single image management). This is a huge benefit.

Another big benefits comes in to play when you think about managing your non-persistent virtual desktop using Mirage. It is currently not supported to manage non-persistent desktops directly with Mirage but with a little workaround it can be done today.

As you know, when deploying a non-persistent desktop, Horizon View is using View Composer to created linked-clones. This is a highly optimised process to deploy virtual desktops fast with as little storage consumption as possible. View Composer uses a template virtual machine (master image), better said a snapshot of this machine, to create the linked-clones. As administrator you always install new software, updates and any other customisation to this master image and the recompose all your non-persistent desktops. This means the next time the user logs in he has all the updated stuff on his virtual desktops.

As already said you are not able to manage a linked-clone virtual machine with View yet but of course you can manage your master image with Horizon Mirage. So you can use Mirage deploy all the application, updates, etc. to your master image, uninstall the Mirage client afterwards and then deploy your linked-clones the way you know it.

Now you are able to manage your persistent and non-persistent virtual desktops with Mirage as well as your physical desktops with the same tool.

Last but not least, from a technical point of view, you can of course manage full clone persistent desktops the same way you would manage a physical desktop with Mirage including operations like centralisation, restore, steady state uploads, revert to snapshot, etc. So technically you are able to do a full backup and restore and all other Mirage tasks with a full clone persistent desktop. In this scenario you will put much more workload on your virtual infrastructure as Mirage needs, like every backup tool, resources to backup and restore all the data.

Please keep in mind that officially only the first scenario is currently officially supported by VMware. The second scenario (Managing the master image with Mirage) is kind of a gray area but works perfectly from a technical point of view. The last scenario (full Mirage functionality on a full clone persistent desktop) is definitely not supported but will work.

Horizon Mirage Layers explained

With the newest release of Horizon Mirage everyone is talking about layers, base images, application layering and so one. If you never have worked with Mirage or another layering technology before you may have seen something like this in the past:

OldLayers

With this layer cake vendors explain and show the benefits of virtualization. Virtualization, as everybody should know by now, is a technique to abstract the logic from the physical ressource. Well-known examples are:

  • You can abstract the operating system from the physical hardware by using virtual machines (e.g. VMware ESXi).
  • You can abstract applications from the operating system by using application virtualization (e.g. VMware ThinApp).
  • You can abstract the user profile from the application and operating system by using user virtualization (e.g. AppSense Environment Mananger)

When using a virtualization product you not just simply abstract the logic but you put something between the logic and the physical ressource to get the abstraction done, products like ESXi or ThinApp for example. At the beginning of the virtualization boom every product had major limitations but today virtualization technologies got mature and most of the limitations are gone. Still there are some types of virtualization which got some limitations, for example you can’t virtualize drivers with any application virtualization products or the big penalties you have to pay in terms of hardware compatibility, performance and end user experience when it comes type-1 client hypervisors.

Horizon Mirage doesn’t use any virtualization product to abstract the logic from the physic, but we still abstract the logic. With Mirage the layers look something like this:

MirageLayersDetailedTo abstract all these layers from each other Mirage uses some clever engineering work. Simply put Mirage takes all the files, registry keys and drivers and puts them in the right layer. Of course this is done differently for each type of layer. The following list describes how this is done for each layer:

  • Driver layer
    For the driver layer the administrator has to import the drivers he wants to deploy manually. Download the driver package from vendor, extract it and import it into the management console. Drivers then can be combined to driver profiles. So for example you could import all drivers you need for your Dell E6500 laptop and then create a driver profile called “Dell E6500” which contains all the drivers you need for this laptop. Drivers then can be assigned to your managed computers based on a variety of matching rules, for example operating system, hardware vendor and model.
  • Base layer
    A base layer is created by installing the Mirage client on a reference machine and then centralizing this machine. A reference machine is a computer installed with an operating system you want to manage and it also contains your core configuration, infrastructure software (e.g. anti virus) and core apps. When you have configured your reference machine with all the software and settings as needed you can create a new base layer. By default the entire content of the reference machine is saved in a base layer. This however can be modified to exclude specific subsets of content.  Also there are some factory rules applied. The base layer is the first thing deployed to a client machine if its completely managed by Mirage.
  • App layer
    As the name says an application layer contains an application. An application layer is not limited to one application, you can also install multiple applications into an application layer. Even ThinApp packages can be distributed via a Mirage app layer (more on this in another post). An app layer is created using a snapshot technique. You install the Mirage client again on a reference system, create a snapshot before you install your application you want to put in a layer, than you install your application and afterwards Mirage creates another snapshot and compares the differences and compiles them into an app layer. An application layer contains everything detected as delta except for changes written to a specific user profile and again some factory rules.
  • User layer
    The user layer contains all the content a user creates on top of the base layer and app layers. This layer is automatically created for every computer managed by Mirage. Mirage knows, based on the base layer and the app layers assigned to the particular computer, what it needs to save in this layer automatically.
Factory rules and policies
Factory rules and policies are set in place by VMware to ensure that nothing is included or excluded in a specific layer which could hinder Mirage or the layers (operating system, applications, etc.) deployed by Mirage to work probably. An administrator can see what factory rules and policies are applied using the Mirage management console.

The miragcle miracle Mirage now performs is to bring all these layers to your computer and merge these layers as if they were never separated. After you deployed the base and app layers to a device you can basically just uninstall the Mirage client and everything will still work as expected.

As you can see Mirage works like a virtualization solution on the management site. You can separate apps, operating system, drivers and user settings/apps in different logical layers but on the end point, the users desktop, everything is merged back together and works like a native system.

This has obviously many advantages compared to solutions like application virtualization products and typ-1 client hypervisors, for example:

  • The user always gets full native performance.
  • There is no hardware compatibility list. As long your device runs Windows everything is fine.
  • The application is installed locally and so apps with drivers and shell integration can be easily deployed.

Besides the centralized image management and provisioning functionalities Mirages can do much more thanks to the layering approach, for example Windows migrations, hardware migrations, and backup and recovery.

Mirage overlaps with many solutions on the market such as software deployment systems, backup and recovery and image management tools. The good thing about Mirage is that you can combine it with other solutions but you can use it also as a standalone product. There is no either or.

If you want to learn more about Mirage have a look at the Horizon Mirage 4.0 Reviewer’s Guide or the product page.

Sources: VMware, VMware (2), VMware (3)