Cost savings from Virtualisation is driving today’s large and enterprise-scale IT infrastructure deployments. However with this comes the need to make more advanced considerations when planning and provisioning compared to the relatively simpler bare-metal configurations of days of old.

There is still a small group of the IT community that maintain a hostile stance towards virtualisation as a whole which almost always stems from the uninformed decisions made during an ultimately unsuccessful wander into the world of virtualisation at some point in the past which has left a bad taste in the mouth.

Virtualisation is obviously a more complex configuration of software and hardware than a bare-metal deployment but the benefits are enormous and can be surmised with one word – density. The ability to run scores of servers in a virtual environment on a single physical host is far more efficient and massively increases cost effectivity.

However, with these benefits comes the requirement of sound planning and knowledge of how hypervisor hosts and their guests operate in order to create a consolidated yet high-performing virtual environment.

One of the primary considerations is virtual CPU allocation and this affects CPU wait time which if carelessly configured can have a drastic performance impact on all the guests on the host.

Conventional logic dictates that if you want a virtual machine’s processing performance to increase then you simply assign it more cores but this is somewhat misunderstood because a machine with a higher number of cores will potentially have to wait longer for that number of processing threads to be available on the physical CPU.

There are of course other factors that determine wait time as well such as the core assignment distribution between all the guests on the host, the number of physical sockets on the host and the amount of logical cores available per socket if hyperthreading is supported on the particular CPU model.

Consider the following example:

• You have a single-socket host running the vSphere, Hyper-V or XenServer hypervisor.
• The host has an Intel 10-Core CPU with hyperthreading enabled for a total of 20 logical CPU cores.
• 9 running virtual machines reside on this host. 8 with 4 vCPUs and 1 with 8 vCPUs. Total provisioned CPU cores = 40 = oversubscription ratio of 2:1.
• When the virtual machines with 4 cores need to access the physical CPU they must wait for 4 logical cores to become simultaneously available for processing to occur.
• When the virtual machine with 8 cores needs to access the physical CPU it must wait for 8 logical cores to become simultaneously available for its processing to take place which depending on the workloads of the other guests could be twice the wait time that the others need to conduct processing.

So from experience the lesson to be learnt here is to allocate a fewer number of CPU cores to a virtual machine to start with and increase it as necessary and if required. This is also stated within the best practice guidelines for virtual machine deployment of VMware, Microsoft and Citrix.

• Plan the vCPU assignments wisely for all VMs on a given host to ensure the best performance.
• Be conservative not carefree with allocations. Don’t assign a large number of CPU cores to a virtual machine that does not need them.
• Check the average CPU allocation across the guests and keep it as uniform as possible.
• If there is a large number of guests with fewer cores and a handful of performance intensive guests with many cores on a moderately-highly oversubscribed host then there is a good chance you will encounter CPU wait time issues.