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?

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.

Best practices for upgrading VMware Horizon Mirage

With the newest version of Mirage released just a few days ago there is often the question how to upgrade the Mirage servers to the latest release.

Luckily the instructions on how to upgrade Mirage servers are documented in the VMware Horizon Mirage Administrator’s Guide (page 265 ff.) and also as a separate KB article called: Best practices for upgrading VMware Mirage (2031711).

Unfortunately one crucial thing isn’t mentioned in the documentation: Do not use the “Create new storage areas.” option during the upgrade process of the Mirage management server.

MirageUpgradeNewStorageArea
If this option is used and the path of the original storage area is entered everything of your Mirage installation (Base Layer, AppLayer, CVD data, etc.) is getting deleted and is lost permanently if you haven’t created a backup before!

MirageUpgradeNewLocalCache

The same is true is when the “Create new local cache area.” is used while upgrading the Mirage server software. This situation is far less critical as only the local cache of the server itself is deleted but no important stuff like base layers and CVD data. This may result in some short-time performance penalties as the cache has to be filled again

So please make sure to keep this in mind before and while upgrading your Mirage servers.

Install Horizon Mirage silently

Testing different versions and new versions of a software product in a lab environment can be very cumbersome if you always have to install servers and clients manually. If you think further automating the installation process of Mirage server components also helps you to dynamically scale your Mirage deployment.

For this reasons I always try to automate the installation process of each product I have running in the lab. While this is most often very easy und nicely documented by the vendors (e.g. VMware Tools or the View Connection Server) this isn’t the case for the Mirage server components.

In the following article I cover how to install each Mirage component silently, beginning with the Mirage client. Please make sure you change the file name for each installer accordingly to the Mirage version and bitness you are using.

Software Prerequisites
Every Mirage component (client, server, console and file portal) requires Microsoft .NET Framework 3.5 SP1 to be installed. Please make sure .NET Framework is installed before trying to install any Mirage component silently.
The /qr parameter
Please make sure you use the /qr parameter to install the Mirage server components silently. Every other MSI unattended parameter like /qb or /qn will fail or prompt to accept the licensing agreement.

Mirage client

The unattended installation of the Mirage client is documented in the official VMware Horizon Mirage Administration Guide on page 52. Also my colleague Kim Nis Neuhauss wrote a detailed article about the different deployment methods of the Mirage client.

The installation of the client is really straight forward.

MirageClient.x64.59447.msi SERVERIP=MirageServer:Port USESSLTRANSPORT=true /quiet

You just have to specify the SERVERIP parameter which should contain the FQDN and the port of your Mirage server and if you use SSL instead of TCP for communcation you have to add the USESSLTRANSPORT=true parameter.

Installing the Mirage servers components isn’t that easy as the parameters aren’t documented but it is of course possible!

Mirage management server

[yellow_box]The unattended installation of the Server components assumes that you already have a supported SQL server up and running on which the Mirage database will be installed on. Please make sure the account which is used for the unattended installation has the appropriate permissions on the SQL server instance.[/yellow_box]

To install the Mirage management server silently you have specifiy some of the following parameters:

Parameter Value Required Description
DBSERVER ServerName Yes This presents the FQDN of the SQL box on which you want to store the Mirage database
DBSERVERINSTANCE InstanceName No This is the name of the SQL instance in which you want to store the database. This parameter is only required if have a dedicated SQL instance of your server (i.e. for SQL Express
SERVICEACCOUNTMODE localsystem | CustomUser Yes Specifies wether you want to use the local system account (localsystem) or a dedicated service account (CustomUser) for the Mirage service.
SERVICEACCOUNT Domain\Username No Needs to be specified if CustomUser is choosen as SERVICEACCOUNTMODE.
SERVICEPASSWORD Password No Needs to be specified if CustomUser is choosen as SERVICEACCOUNTMODE.
ADMINGROUPACCOUNT Domain\Groupname Yes Name of the Active Directory group which will be appointed as Mirage administrators.
AFFECTSTORAGE 1 No Specifies if you want create a new storage areas (1) or let the installer decide (0) if it wants to create a new or use an existing one.
WORKDIR C:\PathToMirageStorage No If AFFECTSTORAGE is set this parameter specifies the path to the storage area.

For a new single-server installation using a local SQL Express installation and the storage area on an additional drive called E: you would use the following installation parameters:

mirage.management.server.x64.59447.msi DBSERVER=localhost DBSERVERINSTANCE=SQLEXPRESS SERVICEACCOUNTMODE=localsystem ADMINGROUPACCOUNT="HorizonFluxMirage Admins" AFFECTSTORAGE=1 WORKDIR="E:\MirageStorage"

To install a multi-server setup with a dedicated service account and SQL server you would use something like this:

mirage.management.server.x64.59447.msi DBSERVER=sql.horizonflux.com SERVICEACCOUNTMODE=CustomUser SERVICEACCOUNT=HorizonFluxMirageService SERVICEPASSWORD=TopSecretPassword ADMINGROUPACCOUNT="HorizonFluxMirage Admins" AFFECTSTORAGE=1 WORKDIR="\\file.horizonflux.com\MirageStorage" /qr

Mirage server

To do an unattended installation of the Mirage server some of the following parameters must be specified:

Parameter Value Required Description
DBSERVER ServerName Yes This presents the FQDN of the SQL box the Mirage database is stored on
DBSERVERINSTANCE InstanceName No This is the name of the SQL instance in which the Mirage database is stored. This parameter is only required if have a dedicated SQL instance of your server (i.e. for SQL Express
SERVICEACCOUNTMODE localsystem | CustomUser Yes Specifies wether you want to use the local system account (localsystem) or a dedicated service account (CustomUser) for the Mirage service.
SERVICEACCOUNT Domain\Username No Needs to be specified if CustomUser is choosen as SERVICEACCOUNTMODE.
SERVICEPASSWORD Password No Needs to be specified if CustomUser is choosen as SERVICEACCOUNTMODE.
AFFECTCACHE 1 No Specifies if you want create a new local cache area (1) or let the installer decide (0) if it wants to create a new or use an existing one.
CACHEDIR C:\Program Files\Wanova Mirage\LocalCache No If AFFECTCACHE is set this parameter specifies the path to the local cache area.
CHUNKCACHESIZE 102400 No If AFFECTCACHE is set this parameter specifies the size (in megabyte) of the local cache area.

For a single-server installation using a local SQL Express installation, a local system account and a 20GB local cache in the default location the following parameters will suffice:

msiexec /i mirage.server.x64.59447.msi DBSERVER=localhost DBSERVERINSTANCE=SQLEXPRESS SERVICEACCOUNTMODE=localsystem AFFECTCACHE=1 CHUNKCACHESIZE=20480 /qr

For a multi-server installation with a dedicated SQL server and service account and also a dedicated local cache drive the following installer switches would the job:

mirage.management.server.x64.59447.msi DBSERVER=sql.horizonflux.com SERVICEACCOUNTMODE=CustomUser SERVICEACCOUNT=HorizonFluxMirageService SERVICEPASSWORD=TopSecretPassword AFFECTCACHE=1 CACHEDIR=E:\MirageCache CHUNKCACHESIZE=102400 /qr

Mirage WebAccess

To install the Mirage WebAccess feature (also known as File Portal) you frist have to install the Microsoft Internet Information Service (IIS) with some additionally features. This can be done using the Server Manager or using two simple PowerShell commands. For a detailed description of what IIS features are needed and how to install them using PowerShell have a look at the following of my articles: Install Horizon Mirage prerequisites via PowerShell.

After you installed the required software components you can install the file portal silently using some of the following commands:

Parameter Value Required Description
ADMIN_VIRTUAL_DIR_VAL VirtualDirectoryName No The folder on which the admin file portal should be reachable, i.e. http://mirage/VirtualDirectoryName
MGMTSERVER ServerName Yes This presents the FQDN of the Mirage management server.
VIRTUAL_DIR_VAL VirtualDirectoryName No The folder on which the file portal should be reachable, i.e. http://mirage/VirtualDirectoryName

To install the File Portal on the same machine as the Management Server using all default setting the following command can be used:

mirage.WebAccess.x64.59447.msi MGMTSERVER=localhost /qr

To install the File Portal on a dedicated machine using different virtual directory names you could use the following command:

mirage.WebAccess.x64.59447.msi MGMTSERVER=mirage-web.horizonflux.com ADMIN_VIRTUAL_DIR_VAL=AdminWeb VIRTUAL_DIR_VAL=Web /qr

Mirage management console

To install the Mirage management console silently you don’t have to provide any additional parameters beside /quiet.

mirage.management.console.x64.59447.msi /quiet
Disclaimer
These unattended installation commands for the server components and the console are not officially documented and therefore most likely not supported by VMware. Please test this in a development environment before using on production systems.

Install Horizon Mirage prerequisites via PowerShell

For the installation of the Mirage server components some specific Windows features are needed.

For the Mirage server, the the management server and the management console Microsoft .NET Framework 3.5 SP1 is needed. The installation of this feature can be accomplished via the Server Manager or via PowerShell.

To install .NET Framwork via PowerShell just start PowerShell as an administrator and then run the following two commands:

Import-Module ServerManager
Add-WindowsFeature NET-Framework-Core

To install the Mirage File Portal (WebAccess) also requires .NET Framework 3.5 SP1 but additionally it requires the Microsoft Internet Information Service (IIS) with some additional components like the IIS 6 Management Compatibilit feature.

Source: http://www.vmware.com/pdf/mirage-administrators-guide-4.pdf, Page 44
Source: http://www.vmware.com/pdf/mirage-administrators-guide-4.pdf, Page 44

To install these features through the Server Manager can be a bit cumbersome and using the following PowerShell commands to install IIS and all the features required by the Mirage File Portal is much easier.

Import-Module ServerManager
Add-WindowsFeature Web-Static-Content, Web-Default-Doc, Web-Dir-Browsing, Web-Http-Errors, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Filtering, Web-Mgmt-Console, Web-Scripting-Tools, Web-Mgmt-Service, Web-Metabase, Web-WMI, Web-Lgcy-Scripting, Web-Lgcy-Mgmt-Console

If you haven’t installed .NET Framework before installing IIS just add the NET-Framework-Core at the end of the Add-WindowsFeature command for the IIS feature installation (and don’t forget to add a comma after Web-Lgcy-Mgmt-Console).