When updating the Mirage server infrastructure to a newer version all Mirage clients are automatically updated the next time they connect to the upgraded Mirage server. During the client update the user gets notified that the client is being upgraded.
While this notification is somewhat non-disrupting sometimes it needs to be deactivated. Of course this is possible with only a minor change to the Mirage desktop service configuration file located here:
C:\Program Files\Wanova\Mirage Service\Wanova.Desktop.Service.exe.config
Open this XML file in your favourite editor and change the following setting from
<add key="showUpgradeBalloon" value="true"/>
<add key="showUpgradeBalloon" value="false"/>
Most customers change this key while deploying the Mirage client using a post-install script. But what to do when Mirage is already up and running, the Mirage clients are deployed and you are planning an upgrade?
Thats even easier. You can centrally change this setting by updating your CVD policy. Here is how:
- Export your CVD policy using the Mirage management console
- Add the text outlined below inside the configuration tags
- Import your CVD policy using the Mirage management console
- Save the policy as new (minor) version
- Assign the updated CVD policy to all your clients
The following parameter has to be added inside the configuration tags:
<Config Name="showUpgradeBalloon" Value="false" />
Please be aware that this entry is case sensitive.
After you edited your CVD policy the XML file should look similar to this example:
<?xml version="1.0" encoding="utf-8"?>
<DesktopPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Config Name="showUpgradeBalloon" Value="false" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmdk" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmem" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmsn" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmss" />
<Directory path="%anyvolume%" recursive="true" filter="*.vhd" />
<Directory path="%anyvolume%" recursive="true" filter="*.vfd" />
With Horizon Mirage 4.3 some new advanced options inside of the CVD policies were introduced.
The new options are:
- Optimize for VMware Horizon View
- Layer assignment only
- Optimize for LAN environments
- Disable client throttling
First I will cover the “Layer assignment only” option, followed by the “Optimize for LAN environments” and “Disable client throttling” options. Last but not least I will cover the “Optimize for VMware Horizon View” option and some additional settings referring to the Horizon View optimization.
Layer assignment only
As soon as this option is set no data (with the exception of some meta data) from the client is uploaded to the server. For this reason you have no backup of all of the end point data and functions like restore to snapshot are not possible. Still it is possible to assign layers (base and app layers) and this way you can use Mirage simply as an image management tool without all the heavy lifting of the centralization (full backup of the client).
Optimize for LAN environments
Because Mirage was developed for centralized management of a decentralized fleet of computers located in different offices behind various WAN connections it heavily optimizes the connection between client and server. For example every file transferred between the Mirage client and server is compressed on the fly. Also a deduplication on file- and block-level is done before the data is transferred. As soon as the Mirage server as well as the client are located in the same local area network compressing and deduping the traffic isn’t really necessary as most of the time there are at least ethernet or gigabit ethernet connections available and this is exactly what this option does. As soon as this option is activated compression and block-level deduplication is deactivated on each CVD which has this policy assigned to. This speeds up the process of centralization in LAN environments and also lowers the resources consumed on the end point/server as no compression and block-level dedupe calculations are done anymore. Last but not least the restore streaming functionality is disabled too when this option is activated.
Disable client throttling
Mirage is developed so it can run in the background without the user knowing that some Mirage task (e.g. layer update or synchronization) is currently running. The reason for this is that the Mirage client monitors the users activity and as soon as the user is doing something on his computer the Mirage client throttles down so that the applications run by the users do not slow down. This is a very useful and highly appreciated feature but in proof of concept or test environments this feature just slows down the Mirage processes. The option “Disable client throttling” also disables network throttling within the Mirage client. Normally the Mirage client throttles down its network traffic to not block any other traffic but when you enable this option also this type of throttling isn’t done anymore.
Until now both features had to be disabled in the Mirage desktop XML config file manually but now it is possible, by enabling this option, to set it centrally.
Optimize for VMware Horizon View
The most prominent new CVD policy advanced option is the “Optimize for VMware Horizon View” one. This option does two things: (1) it marks each CVD assigned to this policy as View desktop and (2) automatically enables the options “Layer assignment only” and “Optimize for LAN environments”. As soon as a CVD is marked as View desktop Mirage limits the number of concurrent operations (concurrent layer updates). As this is currently a cluster wide settings this means that by default no more than 20 View desktops will be updated at the same time.
For example if you assign a new layer to 100 desktops only 20 desktop will get the update at the same time. As soon as one of the first 20 desktops has finished updating the next desktop will be updated until all 100 desktop are finished. Of course you can adjust the number to your needs but you need to make sure that the number of concurrent operations isn’t the too high. If the number is too high this could result in degraded performance and therefore user experience as the underlying hardware can’t handle the additional load.