CPU virtualization adds varying amount of overhead, because of this you may need to fine tune the CPU performance and need to know what are the standard best practices.
Following are the standard CPU performance best practices:
You need to avoid using SMP VMs unless it is required by the application running inside the guest OS. That means if the application is not multithreaded then there is no benefit of using SMP VM.
You should prioritize the VM CPU usage with proportional share algorithm.
Use DRS (Distributed Resource Scheduler) and vMotion to redistribute VMs and reduce contention.
Use the latest available virtual hardware for the VMs.
Reduce the number of VMs running inside a single host. This way, you can not only reduce the contention, but also reduce the fault domain configuration.
You should leverage the application tuning guide from the vendor to tune your VMs for best performance.
To step through this recipe, you need a running ESXi Server, a couple of running virtual machines, and a working installation of vSphere Client. No other prerequisites are required.
Let's get started:
For the first best practice, you need to check whether the application is single threaded or multi-threaded. If it is single threaded, then avoid running SMP VM.
You need to log in to vCenter using vSphere Client, then go to the Home tab. Once there, go to the VM and look at the Summary tab.
Now you can see whether the VM has one vCPU or multiple vCPUs. You see whether it's using them by looking at %Utilization or similar metric for each vCPU. This Summary tab doesn't tell us whether the app is single threaded or multi-threaded.
For the second best practice, you need to prioritize the VM CPU using shares and reservation. Depending on the customer SLA, this has to be defined.
You need to log in to the vCenter using vSphere Client, then go to the Home tab. Once there, go to the VM, right-click on it, and then select Edit Settings.
Now go to the Resources tab and select CPU. Here, you need to define the Shares and Reservation values depending on your SLA and the performance factors. By default, ESXi is efficient and fair. It does not waste physical resources. If all the demands can be met, all will. If not all demands can be satisfied, the deprivation is shared equitably among VMs, by default.
VMs can use, and then adjust the shares, reservations, or limits settings. But be sure that you know how they work first.
For the third best practice, you need to have a vSphere Cluster and have DRS enabled for this. DRS would load balance the VMs across the ESXi hosts using vMotion.
The first screenshot shows that the DRS is enabled on this vSphere Cluster:
The second screenshot shows the automation level and migration threshold.
For the fourth best practice, you first need to see what virtual hardware the VM is running on, and if it is not current then you need to upgrade that. Virtual hardware version can limit the number of vCPUs.
You need to log in to the vCenter using vSphere Client, then go to the Home tab. Once there, go to VM and look at the Summary tab.
In the following example it is hardware Version 8, which is old and we can upgrade it to hardware Version 9.
Now to upgrade the virtual hardware of a VM, it has to be powered off and then right-click on the VM and go to Upgrade Virtual Hardware. It should give you a warning.
Tip
Take a snapshot prior to upgrading in order to mitigate the rare occurrence of a failure to boot the Guest Operating System after upgrading.
Once you click on OK, the virtual hardware version will be upgraded.
For the fifth recommendation, you need to limit the number of vCPUs required by the VMs that would run on the host and the number of sockets/cores available in each physical host. Remember the golden rule of "Don't keep all your eggs in one basket" can be retrieved based on fault domain tolerance and customer SLA. There is no simple answer to this. Monitor the VMs for performance and adjust as necessary.
For the last recommendation, you need to get the vendor application tuning guide and follow that to tune your virtual environment. A typical example is Exchange 2010 Best Practices guide on VMware.