VCOps right-sizing recommendation for vCPU

[tgeyer]

We are utilizing the VCOps Oversize Virtual Machines report to identify vm's with more vCPUs than their utilization justifies.  Many of the report's recommendations are to set vCPU to 1.  Most of the recommendations apply to Windows 2008 R2 vm's.  My old-school rule of thumb has always been to never allocate more vCPUs than the vm's cpu utilization requires, which seems to be the approach taken by VCOps.  The reason was always due to the fact that ESX can schedule 1-vCPU vm's easier and more efficiently than SMP vm's.  In addition, I'd question why VCOps would recommend a 1 vCPU configuration if it did not achieve optimal efficiency.

My collegue believes the vCPU configuration for Windows 2008 R2 vm's should never be below 2, regardless of the vm's cpu utilization rates.  His reasons for this are 1) the Windows kernel is optimized for multiprocessor machines, 2) applications running within the OS cannot take advantage of concurrently-scheduled SMP threads when there is only one vCPU, and 3) the scheduling penalty for SMP vm's was greatly reduced, if not eliminated altogether, with the release of ESX 3.x.

We are running ESXi 5.0 on HP BL460c G6 (2p x 4c) and G7 (2p x 6c) blade servers.

Does anyone know of a whitepaper or some authoritative source that could settle this question for us?

Thanks.

TG

[jklick]

It seems like the three questions might be attacking three different levels, respectively: the OS, the application, and the hypervisor

1 - OS

For kernel optimizations in Windows 2008, is he referencing the improvements with the hardware abstraction layer (HAL)? This is a good reference that relates to that:

In this TechNet article by Mark Russinovich, he explains the changes in 2008. One of the quotes:

"One of the low-level changes to the system is that Windows Server 2008 only includes a version of the kernel designed to work on multiprocessor  systems. In the past, Windows used a version specific to uniprocessors on machines with a single CPU because that version could achieve slightly better performance by omitting the synchronization code  required only in multiprocessor environments. As hardware has become faster, the performance benefit of the optimizations has become negligible, and most server systems today include more than one  processor, making a uniprocessor version unnecessary."

Source: http://communities.vmware.com/message/1773738#1773738

2 - Application

Application requirements will certainly vary. If the application is known to have noticeable performance increase with multiple cores (instead of one), then maybe it's a good idea. Otherwise, it seems that historical CPU usage shows that it may be fine with just one.

3 - Hypervisor

It is true that the CPU scheduler has been greatly improved upon since ESX 3.x; however, I still see people still run into issues with CPU contention all the time (as a result of a high vCPU:pCPU ratio). Basically, these improvements have given more breathing room when it comes CPU allocations, but hasn't made us immune to scheduler related issues.

If you find it helpful, I recently wrote about some other considerations for sizing CPUs: http://www.vkernel.com/reader/items/4-reasons-to-correctly-size-vcpu-allocation

Let us know if this helps or if you have additional questions.