We will be moving to tim.expert

After a very long time without a blog post I wanted to update the readers of this blog about a couple of things:

Since November of last year I am working for Nutanix as a Sr. Systems Engineer in Germany. This is also the reason why it was pretty quite on this site for the last year.

While this blog was focused (as the name implies) on VMware’s Horizon end-user computing product portfolio I though it would be time to switch to a vendor neutral blog name.

Introducing tim.expert.

On tim.expert I will soon start blogging again about different topics like virtualization solutions, software-defined storage, hyper-converged infrastructure and of course all things Nutanix. Maybe I will even be able to squeeze in one or two EUC related posts.

In the meantime some house keeping: All content of horizonflux.com is already migrated to tim.expert. In the summer time I will start redirecting everything to tim.expert and by the end of the year I will take this domain offline.

Tim (not a certified expert).

Bandwidth management with VMware Mirage

Using Mirage in large, distributed networks or even small ones sometimes can be a bit problematic. This is especially true during times in which layers are updated, machines are migrated and so on.

The reason for this is the limited amount of bandwidth available between the Mirage servers and clients. While Mirage works perfectly fine with slow and somewhat limited network connections it still takes what it gets. This means if you have, for example, a 10 Mbit line and you are updating a Mirage managed end point over this connection it will most certainly congest. Because, as I already said, Mirage will use as much bandwidth as available – like almost every other protocol.

This is the reason why it is recommended to use Quality of Service (QoS) in environments where Mirage will be used, especially when branch offices with limited bandwidth come into play. Configuring the existing QoS solution to work with Mirage most of the time is very easy, because Mirage only uses one port (TCP 8000) for communication between client and server. But often no QoS is implemented and implementing it as part of the Mirage project is most often not possible.

Quality of service

While the new Mirage bandwidth limiting feature works very well and is easy to implement, implementing a proper QoS based on the network infrastructure has still some advantages, for example, allowing Mirage to use more bandwidth if the line utilizatization is low.

Based on this experience in version 5.1 of Mirage a new feature called bandwidth limiting was introduced. With the new bandwidth management features you will be able to limit the bandwidth Mirage uses without the need for 3rd party QoS solutions. You are able to specify the maximum amount of bandwidth (in KB/s) Mirage can use for upload and download operations based on the clients IP subnet or Active Directory site. Actually you set the bandwidth limit from the servers point of view, this means you set the bandwidth limit for outgoing (download from the clients point of view) and incoming (upload from the clients point of view) traffic.

Screenshot 2014-11-03 12.43.23

To set bandwidth limits you create a CSV file that specifies how much bandwidth can be consumed for outgoing respectively for incoming traffic based on the location of the client. The location is identified by either the IP subnet or AD site. Here is an example:Screenshot 2014-11-03 12.43.33

For more information on how to set up bandwidth rules in the Mirage management console have a look at the official documentation: Managing Bandwidth Limitation Rules.

Now, let’s talk about the priority of the rules. First of all the order of the entries has no effect (besides on exception I will cover in a moment) on which rule is applied to which end point. Have a look at the screenshot above. As you can see you can specify a rule based on:

  • the Active Directory site,
  • the IP (v4) subnet
  • and a single end point (also based on an IP subnet rule).

For each of these rules you can set up a limit for outgoing and incoming traffic. So, to stick to my example, I limited the bandwidth for the AD site “Branch” to 2500 KB/s, the IP subnet to 8000 KB/s and each of the IP addresses to 5000 KB/s. I set each limit to the same value for incoming and outgoing traffic. To keep it simple for now we will only talk about outgoing traffic (client download).

First of all both clients identified by their specific IP address can download with a maximum speed of 5000 KB/s. Theoretically that would allow them to consume 10.000 KB/s in total in the subnet But because the subnet is limited to 8000 KB/s the max. amount of bandwidth the can be consume in total is 8000 KB/s. Still each client itself is limited to 5000 KB/s. Now, because both clients or to be more precise the IP subnet belongs to the Active Directory site “Branch” the bandwidth is further limited to 2500 KB/s. So regardless of the bandwidth limit for the specific device or subnet the Active Directory site rule in this case wins. But the rule does not win because it is listed last or because AD sites have a higher priority instead it is the rules with the most restrictive limit. If I had set a limit of 500 KB/s to the IP then this limit would be enforced and not the subnet or site limit.

As I mentioned before the order of the entries has more or less no effect unless you specify the same rule twice. Then the latter one will be used.

After the priority of the rules is sorted out let’s talk about the limitation of incoming and outgoing traffic. As you can see you can set both limits (upload and download) independent from each other. This means Mirage bandwidth limitations can even be used on asynchronous connections where the upload bandwidth may be lower than the download bandwidth. For rules including only a single device up- and download operations will never run at the same time as the Mirage client is either uploading or downloading. Rules based on AD-sites or subnets will most definitely run up- and download operations at the same time as they will include more than one devices. Please be aware of this fact and plan your bandwidth limits accordingly. Also make sure you understand that you specify the max. amount of bandwidth that Mirage can use.

While the priority of the rules and the maximum amount of used bandwidth are the basics you need to know to work properly with the Mirage bandwidth limiting feature the following facts are also very helpful and good to know:

  • As soon as you import new rules they will take effect immediately. No restart of the Mirage server services or the clients are necessary.
  • Mirage will not guarantee fairness between clients but from personal testing it looks like that bandwidth is divided equally under full load.
  • If a Mirage client is configured as branch reflector all bandwidth limitations still apply. Layers downloads to the reflector will be limited by the rules applied to it.
  • Bandwidth limits do not apply to transfers between branch reflectors and clients. So clients that download their layer from a branch reflector will not be limited in any way.
  • The auto update feature of Mirage clients are also affected by the configured bandwidth limits.
  • Bandwidth limits will be divided between servers proportionally to the number of connected clients and each server gets a fair share of bandwidth. This means, for example, if you have five servers and a bandwidth limit of 5000 KB/s set for a subnet each server will get 1000 KB/s under full load. Also, for example, if you have two servers with a limit of 5000 KB/s set for a subnet and three clients connect to the first server and two to the second server the first server will get 3000 KB/s of bandwidth and the second one 2000 KB/s.
  • And of course bandwidth rules can be imported and exported using the Mirage server CLI using the getBandwidthRules and setBandwidthRules option.

Thats about it. How do you like the new feature? Anything missing in regards to bandwidth management you may want to see in future version of Mirage?

CloudVolumes, Mirage and ThinApp: when to use what?

Just last week VMware bought a company called CloudVolumes. CloudVolumes is a solution that uses a technique called layering to deploy application in real-time. After the news broke many customers asked what will happen to Mirage, isn’t that layering as well? And what about ThinApp? Do I need ThinApp anymore?

First of all we need to take a step back and have a look on how these products actually work.


VMware Mirage, formerly called Wanova, was developed with physical machines in mind. Mirage completely operates inside the Windows operating system and uses core Windows technologies like VSS. Besides deploying operating system and applications, called base layer and application layers, Mirage supports additional functions like backup and recovery of end points and also Windows migration scenarios. A huge benefit of Mirage, especially in distributed environments with WAN connections, branch offices and roaming users, are the optimisation techniques included. Mirage uses file- and block-level deduplication as well as compression to reduce the amount of data transferred between the Mirage servers and end points as much as possible.

Of course Mirage will work with virtual machines and VDI environments (using full clones) because it operates purely inside the Windows operating system and therefore doesn’t care if it is run on a physical machine, a virtual desktop on top of VMware Workstation/Fusion or even a Hyper-V virtual machine. Mirage also introduced some optimisations especially for VDI environments, for example, disabling compression and block-level deduplication as well as possibility to limit concurrent operations. But still the way Mirage works isn’t really optimised for VDI environments because for each layer update a reboot is required, each deployment operation is done inside each individual desktop including the file dedupe calculation and non-persistent desktops / linked-clones are not supported. In addition VMware doesn’t support back up/recovery scenarios in virtual environments, even though it is technically possible.

While Mirage can be used in virtual desktop environments and it makes absolutely sense for some use cases, e.g. persistent full clone desktops and containerised desktops, there are some use cases where it doesn’t fit quite right and there is a better way – introducing CloudVolumes.


CloudVolumes works very different in comparison to Mirage. It uses hypervisor technologies to optimise the delivery of layers, in CloudVolume terms a layer is referred to as a CloudVolume. Because CloudVolumes uses hypervisor technologies out of the box it only works with virtual machines running on top of VMware vSphere.

A layer, or a CloudVolume, is basically a VMDK containing the application executables, registry and all supporting application data. When the application layer is deployed to a virtual desktop or user the VMDK is mounted to the corresponding virtual machine and the CloudVolume agent running inside Windows is integrating the mounted VMDK so that is not represented as an additional drive but instead integrated in the native file system and registry. For example, if you deploy Mozilla Firefox using a CloudVolume it is not represented as E:\Mozilla Firefox\firefox.exe because it is integrated in the native file system and looks like a natively installed application which is located at C:\Program File\Mozilla Firefox\firefox.exe.

Because the VMDK is read-only the same VMDK can be used for a virtually unlimited number of virtual desktop. Another huge benefit is that layers can be assigned on demand without the need of a reboot.

In addition CloudVolumes supports non-persistent and persistent desktop as well as full and linked clones.


CloudVolumes as well as Mirage are technologies to deploy application. Simply put they are both just a way of transporting application files and registry to a Windows desktop. While ThinApp can also be used as delivery mechanism, especially in combination with Workspace portal, the true power of ThinApp is the ability to isolate an application.

An application deployed using Mirage or CloudVolumes behaves like a natively installed application. It has full access to all installed applications and operating system components and vice versa. This fact makes it simple to deploy applications and gives us a very high success rate when deploying applications this way but it also has the same limitations as any other deployment mechanism that is not application virtualization. You will not be able to run multiple version of an application (e.g. run older version of Internet Explorer in parallel to the latest one) and you won’t be able to prevent DLL conflicts, just to give you two examples.

With ThinApp, because it adds a layer of virtualization, you will be able to run applications isolated from each other and from the operating system. This allows running applications independent from other native installed and virtualized applications and therefore prevent conflicts. It also makes the virtualized applications, to a certain degree, independent from the underlying operating system.

When to use what?

First of all lets discuss when to use Mirage and when to use CloudVolumes. Currently it totally depends on the use case.

When it comes to managing physical end points and containerised desktops Mirage is the way to go. The features Mirage offers, e.g. distribute layers in a highly optimised fashion (file- and block-level dedupe, compression) and backup / recovery functionalities, are huge benefits and must have features in these environments.

In VDI environments, especially in environments in which linked-clones are used, CloudVolumes is the perfect fit. It allows us, in a best case scenario, to use just one golden master and add all user and department specific application using layers. In addition adding an application to a desktop is simply put just a mount of a VMDK the overhead from a performance point of view is negligible especially in comparison to Mirage.

What about full clone, persistent VDI environments? In this case Mirage as well as CloudVolumes offer great functionality and need to be evaluated. But what if I tell you that CloudVolumes enables you to have a persistent desktop experience on top of a non-persistent linked-clone using CloudVolumes. CloudVolumes allows users to install their own applications. All changes are dynamically redirected to a user-specific writable CloudVolume. This volume is automatically mounted when a user logs on to a non-persistent desktop. This makes CloudVolumes a rather nice fitting solution for persistent desktop environments because you can still efficiently manage your master image using linked-clones (View composer) and add user/department specific application using CloudVolumes and optionally even support user-installed application using writable CloudVolumes.

Last but not least there is server-based computing. While Mirage does not support managing server-based operating systems this can be done with CloudVolumes today.

Did I forget ThinApp? No, I didn’t. ThinApp can and should be used complementary on top Mirage and/or CloudVolumes. If you require the benefits of isolating an application, e.g. running an old version Java for a specific application, you can just add this package to a Mirage application layer or a CloudVolume. Because, as I already said, CloudVolumes and Mirage are both just a way to deliver an application, and an application virtualized using ThinApp is still an application that needs to be delivered.

Upgrading VMware Mirage 4.x to 5.0

As VMware Mirage 5.0 is now available many want to upgrade to the latest version. While the way of doing an upgrade from 4.x to 5.0 has not change it will change with 5.0 going forward.

Up to version 5.0 you need to uninstall old versions of the Mirage server components first and then install the new ones. This needs to be done in a specific order:

  1. Uninstall all Mirage servers
  2. Uninstall Mirage management server
  3. Uninstall additional components (Mirage management console, WebAccess and WebManagement)

After everything is uninstalled the components need do be installed as follows:

  1. Install Mirage management server
  2. Install Mirage servers
  3. Install additional components

It is most important to (un)install the Mirage management server and Mirage server in the right order. The remaining components can be (un)installed in no particular order. For more information about upgrading Mirage have a look at the following article: Best practices for upgrading VMware Horizon Mirage.

For future upgrades, for example, from Mirage 5.0 to Mirage 5.next it will not be required to uninstall the Mirage server components first. You will be able to just run the MSI of the new Mirage version and it will automatically detect all existing settings (like database configuration, service account used, cache and storage location) and then do the upgrade.

From a technical point of view the upgrade from 4.4.x to 5.0 could also be done using this new mechanism. But because some advanced error handling needed to be implemented in the Mirage server software, which was implemented with Mirage 5.0 and is not available in prior versions of Mirage, it is not supported and therefore not recommended to use this upgrade method when upgrading from 4.4.x to 5.0. The traditional way via the (un)install upgrade method must be used.

Post-scripts in VMware Mirage

For many operations VMware Mirage allows to run so-called post-scripts.
Post-script are scripts that run on the endpoint after one of the following operations is completed:

  • Windows migration
  • Base layer provisioning
  • Base layer assignment
  • App layer deployment

A post-script allows you to run scripts and programs and do customisations.

Practical use cases are:

  • Delete the Windows.old directory after a Windows migration
  • Customise configuration files based on computer name
  • Install OEM software based on the specific hardware type
  • Deploy applications that are not yet compatible with app layers
  • and many more

All post-scripts are located under %ProgramData%\Wanova\Mirage Service and need to be included in the base layer respectively in the app layer in case of the post-app layer deployment script.
Below you find an overview of the different script names that are used.

Script file nameExecution time
post_migration.batPost-Windows migration
post_provisioning.batPost-Base Layer Provisioning
post_core_update.batPost-Base Layer Assignment
post_layer_update_*.batPost-App Layer Deployment

By default the post_migration.bat and a file called post_bi_update.bat are located inside the %ProgramData%\Wanova\Mirage Service directory. While you can freely modify the post_migration.bat to execute programs and scripts after a Windows migration it is highly recommended not modify the post_bi_update.bat script. The post_bi_update.bat script is more or less just a wrapper for the post_provisioning.bat and post_core_update.bat.

So, if you want to run scripts after a base layer provisioning or assignment you first have you create the corresponding script (post_provisioning.bat or post_core_update.bat) inside the %ProgramData%\Wanova\Mirage Service directory. Those two script are call by the post_bi_update.bat so there is no need to modify this file directly.

Inside the scripts you can basically do whatever you want you just have to be aware of the following:

  1. The scripts and therefore everything you do inside the scripts are executed in the context of the system account
  2. Make sure your script returns a proper error code. Return a zero (0) if the script execution is successful. Everything else is interpreted as an error and logged as such in the Mirage event log.
  3. By default there is a 300 second (5 minute) time out for post-scripts. If the script isn’t finished during this timeframe Mirage will no longer wait for the script and proceed.

The screenshots above showing a post-script error and time out message in the Mirage event log.

While most scripts are placed inside the base layer the post-app layer deployment script needs to be included in an app layer. During the app layer recording process create a file called post_layer_update_*.bat in the folder %ProgramData%\Wanova\Mirage Service. Of course you need to replace the asterisk (*) with a unique name. You have to make sure that each app layer has a unique script name.

Example: post_layer_update_firefox22_0485345.bat

Unfortunately troubleshooting post-scripts can be bit cumbersome as you have no chance to see the script execution interactively. Therefore it is recommended to implement logging functionalities in your script so that each step is recorded in a log file. A perfect location for log files created by post-layer scripts is the Mirage service log directory located at %Program Files%\Wanova\Mirage Service\Logs. Just make sure you choose a unique log file name.

Page 1 of 1512345...10...Last »