Ask the Architect about the Next-Gen Desktop

Daniel Feller

Subscribe to Daniel Feller: eMailAlertsEmail Alerts
Get Daniel Feller via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Virtualization Magazine, Citrix Virtualization Journal, Desktop Virtualization Journal, Infrastructure 2.0 Journal

Citrix Virtualization: Article

Storms Can Kill Your Virtual Desktop

Top 10 mistakes to avoid with virtual desktops

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.

More Stories By Daniel Feller

Daniel Feller, Lead Architect of Worldwide Consulting Solutions for Citrix, is responsible for providing enterprise-level architectures and recommendations for those interested in desktop virtualization and VDI. He is charged with helping organizations architect the next-generation desktop, including all flavors of desktop virtualization (hosted shared desktops, hosted VM-based desktops, hosted Blade PC desktops, local streamed desktops, and local VM-based desktops). Many of the desktop virtualization architecture decisions also focuses on client hypervisors, and application virtualization.

In his role, Daniel has provided insights and recommendations to many of the world’s largest organizations across the world.

In addition to private, customer-related work, Daniel’s public initiatives includes the creation of best practices, design recommendations, reference architectures and training initiatives focused on the core desktop virtualization concepts. Being the person behind the scenes, you can reach/follow Daniel via Twitter and on the Virtualize My Desktop site.