Beware of VDI Defaults

Default configurations are great in that they make the setup and configuration easy. Unfortunately, they don’t work for all environments. In fact, if you simply use the defaults for an entire virtual desktop deployment, you will miss out on tons of optimizations to allow your environment to scale. Simply following the defaults is the 2nd most common mistake people make when implementing XenDesktop. The other 8 discussed so far are:

10.  Not calculating user bandwidth requirements

9.    Not considering the user profile

8.   Lack of Application Virtualization Strategy

7.  Improper Resource Allocation

6.  Protection from Anti-Virus

5. Managing the incoming storm

4. Not Optimizing the Desktop Image

3. Not using your Cache Wisely

Let’s look at the XenDesktop controllers. At a high level, the XenDesktop controller is responsible for:

  • Authenticating users against Active Directory
  • Enumerating available resources
  • Creating registrations for newly started virtual desktops
  • Maintaining an active heartbeat with online virtual desktops

When XenDesktop is installed, many architects fail to optimize the controller and simply install with default configurations (farm master, XML broker, Web Interface). This configuration is perfectly reasonable. XenDesktop can function with a single controller (this is the configuration I have in my own lab). However, during boot and logon storms, where hundreds or thousands of users connect to the environment in a short amount of time, the controller can become a bottleneck.

The controller bottleneck can result in long logon times or even denied service. By separating controller functionality across multiple servers, the overall XenDesktop farm can support more virtual desktops and respond faster.

First, all XenDesktop implementations should have redundant controllers to provide fault tolerance. For environments that are expected to scale into the thousands of hosted VM-based VDI desktops, it is often recommended to separate the controller functionality across a minimum of five servers all of which can be virtualized. The role designation across the five servers would be as follows:

Parameter Description Values
Master Controller The master controller is in charge of the overall XenDesktop farm operations. It also maintains the correct number of idle desktops within the workstation groups by communicating with the virtualization layer (XenServer, Hyper-V or ESX).

If the Master fails, a secondary, dedicate server can be used. If one is not defined, one of the XML brokers will be used.

Specify the XML controllers as backup controllers by modifying the registry:

  • Key: HKLM\Software\Citrix\IMA\RUNTIME\
  • Type: Dword
  • Value: 1

To disallow the Master controller from accepting virtual desktop registrations, modify the following registry key:

  • Key: HKLM\Software\Citrix\DesktopServer\
  • Type: Dword
  • Value: 0
XML Controller (x2) The XML controllers are responsible for registering virtual desktops, authentication and enumerating users. Configure Web Interface to use the XML Controllers as the farm servers. This will only use these two servers for authentication and enumeration activities.

Specify the XML controllers as backup controllers by modifying the registry:

  • Key: HKLM\Software\Citrix\IMA\RUNTIME\
  • Type: Dword
  • Value: 2
Web Interface (x2) The Web Interface servers provide the end user interface for authentication and desktop access. Configure Web Interface on redundant servers t offload the processes from the Master and XML Controllers.

By separating out the controller roles into three roles across five virtual servers, a XenDesktop farm is able to host 5,000+ hosted VM-based VDI desktops. Of course the maximum number for any implementation is based on numerous factors like logon rates, acceptable logon time, and hardware. What if you are creating a farm that is less than 5,000 desktops but more than 2,000 and you are looking at reducing the numbers of servers? The best option would be to combine the XML Controllers and Web Interface servers.

But in the end, the point to remember is that you need to optimize your environment and done just rely on the defaults.

Daniel – Lead Architect

4 thoughts on “Beware of VDI Defaults”

  1. […] The XenDesktop controller scalability is based on the boot, logon and logoff storms. The greater the storm, the less scalable the solution is. On average, a 2 controller system should be able to support 3000-4000 desktops. BUT (and this is a big but), if one of those controllers fails your scalability will drop fast. That’s why it is good to have 3. Three controllers should be able to support the 3000 desktop load even in the event of failure of one of the DDCs. Also, make sure you configure them appropriately and avoid the defaults. This means separating functionality across the three controllers. […]


  2. […] #2 – Using VDI defaults Default settings are great for getting a small Proof of Concept up and running quickly. But as you scale up your VDI environment, there are a number of things you should do. If you ignore them, performance will suffer, which means that users will be upset, which means that your VDI project is more likely to fail. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.