In a series of blog posts, I'm going to be covering some of the basics that people just happen to overlook. Let's forget about cloud and look back to the real reason why we started virtualizing in the first place, the virtual machine. The virtual machine is key component to cloud, but having machines that are lean and clean allow greater density and better performance.
I've gone into plenty of environments and every single VM is configured with 2vCPUs or more. Why is this such a problem? It all comes down to CPU cycles and ready time.
We as VMware admins have a virtualize first policy, but even more so, we should have a 1 vCPU first policy. Setting new virtual machines to 1 vCPU will result in an environment that won't be fighting for CPU cycles. A 2 socket server with quad core processors will give 8 cores of CPU on a host. A VM running on 1vCPU can use any one of those 8 cores whenever it's available. The "whenever it's available" is referred to as CPU Ready Time and can be viewed in ESXTOP. The ready time of a virtual machine, which is measured in milliseconds, is best described as the VM was ready to execute but had to wait for CPU resources. There in lies the problem with 2vCPU, 4vCPU and up VMs.
- 1 vCPU VM - can execute it's CPU cycle when any 1 of the 8 cores
- 2 vCPU VM - can only execute CPU cycle when 2 of the 8 cores are available
- 4 vCPU VM - can only execute CPU cycle when 4 of the 8 cores are available
- 8 vCPU VM - can only execute CPU cycle when all 8 cores are available
Virtual SMP (Symmetric Multi-processing) is the capability of a virtual machine to use more than 1 processor. In a physical environment, having more physical cores is always better, but not in a virtual environment. As seen in the chart above, there is always a better chance that 1 vCPU VMs will have their CPU cycles executed faster than an environment that is always waiting for 2 or more CPU cores to be available.
vSMP use cases all depend on the app. Even if the operating system is multi-processor aware, it won't matter unless the app is multi-threaded. Some of those apps are SQL, Oracle, Exchange, Citrix, etc. If the virtual machine doesn't fit into this category, then keep it at 1 vCPU. There will be use cases for VMs that need 8 vCPUs, but keep in mind that it's probably a heavy server that might dictate the need for it's own private host. Even though it uses its own vSphere host, the 8 vCPU VM can still have all the same virtualized benefits as 1 vCPU VMs.
If a request from an application owner ever arrives at your inbox asking for a new VM with multiple vCPUs, make sure the application they are installing is multi-threaded and will really benefit from vSMP. Do your own POC with the application owner and have the application on a VM running on a 1vCPU VM and 2 vCPU VM and see which one outperforms the other. Moving your environment in this direction will allow for greater VM density on your host and better performance for your applications. I've touched on building new VMs with 1 vCPU, but what if you want to start removing vCPUs? I'll get to that on another post describing HAL and scripts available to change it.
**UPDATE**
So it seems that I spoke to soon. Thanks to my replies below, it seems like this argument is for older versions of ESX. The CPU scheduler has advanced to a point where it's very relaxed.
It's possible to give a VM 4vCPUs and if the application is threaded, then the application dictates how many CPU cores need to be available to cycle. If a 4vCPU VM running a dual threaded application, then the VM will execute when there are 2 cores available.