Beware of Improper Resource Allocation


If you ask me what type of desktop I need, I’m going to say, 2+ cores with at least 4+ GB of RAM, 500+GB hard drive, etc. If you look at what I really need, you will see 1 core and maybe 2 GB of RAM. In fact, when I look at my resource consumption, I get close to 2 GB of RAM by the end of the day due to the number of applications I have running, memory leaks in some of my applications, and applications not freeing up memory when closed.

Like me, many users only consume a fraction of their total potential desktop computing power, which makes desktop virtualization extremely attractive. By sharing the resources between all users, the overall amount of required resources is reduced. However, there is a fine line between maximizing the number of users a single server can support and providing the user with a good virtual desktop computing experience.

Improperly allocating resources to the virtual desktops is the 7th most common mistake make. Other mistakes, discussed previously, include:

10.  Not calculating user bandwidth requirements

9.    Not considering the user profile

8.   Lack of Application Virtualization Strategy

One of the lessons we learned from virtual desktop implementations is trying to push the hypervisor, any hypervisor, too hard results in a poor user experience. The following recommendations help optimizing the environment by focusing on the hypervisor:

Parameter Hypervisor Description
CPU Allocation Citrix XenServer
Microsoft Hyper-V

VMware vSphere

Users should start with a single vCPU and be granted a second if needed due to the following:

  • Most user-based applications are only single-threaded and will not benefit from a multiple CPU configuration.
  • Many user applications do not require significant amounts of processing, which negates the need for more CPU power.
  • By allocating multiple vCPUs for each virtual desktop, extra resources are required to switch requests across the different cores.
Command Tuning Citrix XenServer
Microsoft Hyper-V

VMware vSphere

The XenDesktop controller sends low-level commands to the hypervisor layer to perform tasks on the virtual machines (start, stop, reboot, etc). If too many tasks are sent out simultaneously, the connection to the hypervisor layer can become sporadic. These tasks often have a large impact on the server resources, which impacts the users. It is advisable to throttle the number of commands sent.
Transparent Page Sharing VMware vSphere Transparent Page Sharing allows the vSphere hypervisor to share portions of memory that are identical between virtual machines. This has the potential to improve the virtual desktop performance by having a positive impact on memory consumption.

This feature will typically only provide value in older operating systems, like Windows XP and Windows Server 2003, which have 4KB memory pages.  Newer operation systems, like Windows 7 and Windows Server 2008, have large memory pages (2MB) by default. The larger memory pages makes the likelihood of finding exact duplicates of memory very difficult. .

Memory Ballooning

Memory Overcommit

VMware vSphere

Note: XenServer and Hyper-V support for dynamic memory is new. It is assumed the results will be similar, but testing is required.

Memory ballooning or memory overcommit shifts RAM dynamically from idle virtual machines to active workloads. Memory ballooning artificially induces memory pressure within idle virtual machines, forcing them give back memory so other virtual machines can consume it (each hypervisor does it differently but the overall concepts are similar).
In practical applications, this has shown to be an impediment to positive user experiences. Forcing virtual desktops to free up memory is only a temporary solution. If a large group of idle or low-usage virtual desktops become active (after lunch, for example), they will require more memory. But if many of the virtual desktops on the same hypervisor are experiencing increased loads, where will the extra memory come from? With no free memory, the hypervisor is forced to page to disk, which is slow.

A desktop is not a server. A desktop is running desktop applications which often have more memory leaks and poor cleanup processes when compared to server applications. Most desktops consume more memory as the day progresses due to these leaks, which will put strain on any overcommit feature. It is advisable to disable this feature.

What other suggestions do you have for optimizing the hypervisor in a desktop virtualization world?

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 9, 2010, in Top 10 Virtual Desktop Mistakes and tagged , , , , , , , , , , . Bookmark the permalink. 7 Comments.

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 467 other followers

%d bloggers like this: