If you were asked what desktop resources your needed how would you answer? 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-3 GB of RAM. In fact, when I look at my resource consumption, I get close to 2.5 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
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? I expect to hear quite a few comments, especially around memory overcommit and ballooning portion.


Lead Architect – Worldwide Consulting Solutions

Follow Me on twitter: @djfeller

My Blog: Virtualize My Desktop

Questions, then email Ask The Architect

Facebook Fan Page: Ask The Architect