Rush hour. Something we all can relate to. Way back in time when I used to go to an office daily, I hated rush hour.  If I left home at a certain time, it would take me 45 minutes just to get to the office. But if I left just 15 minutes earlier, that same 45 minute trip would only take 15 minutes.  You might be asking yourself what this has to do with virtual desktops. Well, it’s all about managing a storm. I managed the rush hour storm by changing the time I left for work in the morning.  With virtual desktops, we need do something similar. If you don’t, you will encounter the fifth mistake in my list of top 10 mistakes to avoid

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

As you know, most organizations have users arriving and logging into their desktops at roughly the same time. We recommended the use of the XenDesktop group idle settings to prepare the environment for the user logon storm by booting desktops so many minutes/hours before the users arrive. This makes the desktops immediately available for users and allows the system to recover from the massive boot storm. However, when the workstation group’s defined boot time is reached, the controller might try to start thousands of virtual desktops simultaneously. Welcome to the boot storm.

A virtual desktop bootup process incurs the largest hit to the environment than anything else. The XenDesktop controller must tell the hypervisor to start a new desktop and the hypervisor subsequently allocates resources. Sending too many requests to the hypervisor can overwhelm the hypervisor’s management layer (VMware vSphere, Microsoft Hyper-V and Citrix XenServer).   We can manage the storm by configuring the maximum number of simultaneous startups the controller can request. This is done, very easily I might add, by doing the following:

• On the XenDesktop Master Controller, edit the file: C:\Program Files\Citrix\VmManagement\CdsPoolMgr.exe.config
• Locate the MaximumTransitionRate entry and use a value of 20 to 40 (change based on actual environment parameters). For example, if you are running on vSphere and using DRS, a lower value is recommended than on implementations without DRS.  The value entered forces the XenDesktop controller to limit the number of requests that are sent to the hypervisor’s management layer.

This setting should be made to all XenDesktop controllers in the event the master fails and a backup takes over.  We can control the storm. We have the tools to do it. And now you have the knowledge.

• Virtualize My Desktop