Best practices for allocating resources to virtual desktops
It's important to do a good job allocating resources to virtual desktops. Make sure you understand your VM system and allocate based on your users.
It's easy to think of virtual resources as a big elastic mass of memory, storage and CPU, but they're backed by physical ones and need to be allocated with the same care you'd give to more conventional resources.
The easy way to think about allocating back-end resources for virtual desktops is to take the memory and CPU load associated with each desktop system and divide it by what the server can safely provision. That might work if you're only provisioning a few desktops at a time, but if you have dozens or hundreds of virtual desktops, this method makes it easy to miscalculate what's actually available or what you need, resulting in drastically over- or under-provisioned systems.
Here are some pointers to help you determine the best ways to allocate hardware resources for your virtual desktop environment.
Understand the methodology for your VM system
Not all virtual machines (VMs) are created equal; each one has its own way of aggregating resources, Knowing how each VM allocates resources makes it easier to determine the best way to complement the user's virtual desktop needs.
More on allocating resources
Don't neglect VM resource allocation
How to use Resource Governor to allocate resources
Best practices for resource allocation and workload management
VMware, for instance, has a resource pooling system that allows you to keep the allocation of resources separate from the underlying hardware. It also lets you pool resources so you don't have to set up machines individually.
Microsoft Hyper-V can dynamically allocate memory, so it's possible to have desktops that use "burstable" memory allocations: desktops that start with a low amount of memory and then have more allocated based on need, rather than allocating the entire amount of hardware requirements at once. With VMware, dynamic memory allocation is the default behavior, so if you'd rather set hard limits, you should do so manually.
Another thing to keep in mind is the way the VM handles multiple instances of the same OS and how it consolidates memory usage between them. For example, much has been written about the way Windows 7's Address Space Layout Randomization made it more difficult for VMware's Transparent Page Sharing to work properly. Again, you must let your environment's needs speak. If you're inclined to add a couple more desktops to the same hardware, try tweaking the hardware allocation on each one.
Allocate based on user load
Allocate resources to virtual desktops not based on the VDI system you're using, but instead based on the user's workload. The more closely you can tie resource allocation to the users and their behaviors, the more accurately you'll be able to give them the resources they actually need.
You can assign resources based on an individual level, or departmentally. The ideal approach would be to create organizational units that span departments and provide containers for people with both low- and high-usage profiles. If you have a department where only a few people use memory-intensive applications, for instance, you can set low default memory for those virtual desktops but keep a safety margin for the machines that occasionally spike.
In this situation, you should look into what the exact application load is like. If someone runs a server that attempts to use as much RAM as possible, that person is not going to be a good candidate for this kind of allocation.
As far as CPU goes, a two to one ratio of virtual CPUs to logical CPUs is a good idea. For every two virtual cores in your VMs, you can have a single logical core on the server. This ratio assumes a modest processor workload. If you know certain people are heavy CPU users, you may want to either put them in a separate resource pool or even consider giving them a dedicated physical machine rather than a virtual desktop.
Don't forget about the network
The network bandwidth you have available to the server (and the clients) is another hardware resource that's easy to overlook.
One expert suggests that you can confine VM-to-VM traffic to its own internal virtual network. This is useful if your virtual desktops talk not just to each other, but also to another server resource in a VM, such as a database server or internal business-logic Web server. Traffic from the VMs themselves to your clients should be on their own dedicated connections whenever it's practical.
Alternative: Published desktops vs. virtual desktops
If you find that the amount of server resources you have to share really doesn't cut it, consider switching to a published desktop model (if your clients can support it). This is essentially the Citrix XenApp model, where the applications -- rather than the entire OS -- run on the server. You don't have to do this unilaterally, either. You can use application delivery tools such as XenApp for only the user seats, servers or loads that work best with it.
This approach generally works best when many people run the same clutch of applications, and when those apps are generally not very demanding, such as basic line-of-business applications. When many users run more demanding applications, full virtual machines are usually the better option.
