A Virtual Desktop Storm Approaches


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 anecdote 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.

Daniel – Lead Architect

About these ads

About virtualfeller

Daniel Feller, Lead Architect at Citrix, is responsible for providing architecture and design recommendations for organizations looking to experience an environment where users can work and play from anywhere.

Posted on June 22, 2010, in Top 10 Virtual Desktop Mistakes and tagged , , , , , , , , , , . Bookmark the permalink. 7 Comments.

  1. Daniel,

    That’s one way to fix the problem. Some customers might run into challenges as the try to scope for max concurrency and have specific time frames when users come and go. Another option is to put an ILIO appliance between the hypervisor and storage. This will boost read and write IOP’s from 50,000 to 150,000 eliminating the bottleneck.

    Robert

  2. True. I stopped by the Atlantis Computing booth at BriForum and got an overview of the technology that allows for the reduction in storage requirements (IOPS). Although I’m not certain how much of an improvement it would have in day-to-day user activities, it does seem like it would have a major impact on reduction of IOPS during bootup processes.

  1. Pingback: Not Optimizing your Virtual Desktop Image « Virtualize My Desktop

  2. Pingback: Not Spending Your Cache Wisely « Virtualize My Desktop

  3. Pingback: Beware of VDI Defaults « Virtualize My Desktop

  4. Pingback: Improper Storage Design for Virtual Desktops is a Killer « Virtualize My Desktop

  5. Pingback: Top Ten VDI Mistakes | Moose Logic Blog

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 462 other followers

%d bloggers like this: