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 192.168.87.0-254 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 192.168.87.0/24. 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 192.168.87.100 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?

What’s new in VMware Horizon Mirage 4.4 (Tech Edit)

Today VMware released version 4.4 of Horizon Mirage. Even if the official version is just a minor change there are major new features in this release.

In this article I try, like I did for ThinApp 5.0, to summarise and give an overview of all the new features included in version 4.4 from a technical point of view.

Windows 8 / 8.1 support for disaster recovery scenarios

First of all the installation of the Mirage client is now supported on Windows 8 and 8.1. While the full feature set, especially layer management and migrations, isn’t yet support the disaster recovery scenario is fully supported in Mirage 4.4. The disaster recovery scenario contains file/full system recovery and restore as well as self-service recovery using the Mirage file portal and client context menu. One thing important to know is that restore operations for Windows 8 devices can only be performed within the same operating system version, for example, Windows 8.0 to Windows 8.0 or Windows 8.1 to Windows 8.1. But using Mirage 4.4 you will be able to downgrade a Windows 8/8.1 device to Windows 7. This feature is more then welcome when you get new hardware preinstalled with Windows 8(.1) and want to deploy your corporate standard Windows 7 image using Mirage.

To support Windows 8 and Windows 8.1 Mirage now supports version 6.3 of the User State Migration Toolkit (USMT). Mirage now actually supports three versions of USMT:

  • USMT 4 or 5  for Windows XP to Windows 7 migrations and user data restores
  • USMT 6.3 for Windows 8 and 8.1 for user data restores

Mirage44USMT

The import function also was enhanced to block the import of USMT 4.0 if it does not include the Office 2010 hotfix.

Mirage DMZ edge gateway

The ability to connect external / roaming users to Mirage without VPN was request from many clients. While Mirage always supported to work via VPN most users aren’t connect to VPN all the time. Therefore Mirage 4.4 introduces the Mirage gateway. The Mirage gateway is a hardend Windows service which normally will be deployed in a DMZ and is made available over the internet. This allows the Mirage client to securely connect (SSL is a requirement) to the internal Mirage infrastructure, tunnel through the Mirage gateway, if the machine is successfully authenticated. The authentication is done by the user itself when the Mirage client connects to the Edge gateway the first time. When the username and password is validated a is token created and stored for future authentications. It is possible to set a time-out for the token so a re-authentication, to make sure the device is still allowed to connect to Mirage, would be required. A Mirage edge gateway supports up to 1000 end points per server and multiple edge gateways can be deployed.

One thing to mention is that the Mirage gateway allows features like file restore, layer management and centralisation to work for distributed users. But operations which require the end point itself to communicate with the Active directory, for example full system restores of domain joined computer or Windows migrations, are not supported using the gateway because it only tunnels Mirage specific traffic and nothing more.

Support for updating Horizon View agents via Mirage (app) layers

Following the support of managing full clone persistent desktops in Mirage 4.3 the newest release of Mirage now supports updating Horizon View agents from version 5.3 to future releases. As you can see the integration of View and Mirage proceeds further and makes managing persistent desktops much easier. The ability to do Horizon View agents upgrade via Mirage application or base layers makes migrations to newer View releases much easier as all persistent desktops can update using as simple 2-step process.

  1. Create an updated app or base layer containing a future View agent release
  2. Deploy the layer to all clients and after a reboot the update is done

Additionally, no 3rd party tools are required to manage full clone persistent desktops.

Do Windows migrations without centralising the end point

In Mirage 4.3 the ability to do layer management only was introduced. This allowed you to deploy application and base layers to desktops without centralising them. This way you can do central image management for all your end points without using Mirage backup / disaster recovery functionalities. In Mirage 4.4 this function was enhanced to support Windows 7 migrations without the need to centralising the client first.

While you will lose the possibility to revert your desktop to your old Windows version in the case something goes wrong the storage requirements are much less. Therefore the most complex part (storage) of a Mirage infrastructure design is no longer needed. You just need a small amount of storage to hold your base and application layers, drivers and USMT.

Enhancements to the file portal and web management

The most prominent change to the Mirage file portal and the web management is the requirement of a SSL certificate. Access to both services is now only possible through a HTTPS connection. This decision was made to protect user (and admin) credentials and data accessed using both portals. So please make sure when you upgrade to version 4.4 to have a SSL certificate ready to use on your IIS hosting the file portal and web management.

The file portal was enhanced to allow users to allow multiple file portal at once.

Mirage44FilePortalMultiSelect

The web management  got some minor face lifting and also a new mass centralisation functionality which allows you to centralise many clients at once by simply selecting them or applying a rule.  The mass centralisation functionality can be access by clicking the “pending devices” tile on the dashboard.

Mirage44WebMgmtMassCentralization

Better client identification

Last but not least in Mirage 4.4 the client identification was enhanced. In prior version of Mirage the client was identified by using the clients UUID and BIOS identifier. Unfortunately sometimes, when these value were not available or could not be read, Mirage misbehaved. To solve this issue all clients are now identified not only by the UUID and BIOS identifier but also using a attribute, an auto-generated GUID.

Release notes, documentation and download

Using the buttons below you find direct access to the VMware Horizon Mirage 4.4 release notes, the documentation and the download (requires a MyVMware account). With Mirage 4.4 also a nice new VMware Horizon Mirage Getting Started Guide (PDF direct link) is released.

I hope you enjoy this release as much as I do and if you have any comments or questions just leave them below.

Release Notes | Documentation | Download

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.