We talked about memory restrictions in part 1 of this series, but lets now shift our focus to CPU resources. This is a multi-headed beast in the arena that needs tamed. If you have an application that requires a lot of CPU processing power, you ask the VMware administrator for more than one processor. However, in doing so, you may have just set yourself for a pain like an invisible poison floating the stream. At times the VM will perform great, but other times you notice great slow downs. You might be a victim of what is known as High CPU Ready %. You could also be a victim of processor throttling, also known as a CPU limits.
Ultimately the more virtual CPU assignments you have the harder your VM will fight for those processor cores to perform work. After all, there are multiple VM contestants in the arena fighting for time on the processors. So the big lesson here is:
Next let’s assume you do need more than one virtual processor, and the Game Master is graciousness enough to grant you this luxury. The processors on a physical host are laid out on sockets on the motherboard. Each socket has at least one core to process information. In today’s modern datacenter each socket usually has at least two cores, sometimes many more. On top of that each core may have the multi-thread ability. So a single host can appear to have 64 cores available in multiple ways. If all of the cores/threads are filling up on processing then we now begin to have contention for the CPU resources as a whole. When the time that it takes to process information elevates you then have the condition previously mentioned called High CPU Ready %. Again, you will not be able to detect this from within the virtual machine very easily other than having your fans(end users could possibly be labeled as your fans) call you screaming.
He or she should be able to provide these even down to the timeframe for when the slowdown occurred.
With any luck, the VM admin will hopefully have issued a vMotion action on your VM to get it moved to a more suitable host. At a minimum, the VM admin should have at least identified which VMs are causing the most CPU contention, and eliminated them from your host. If not, ask for a vMotion ASAP.
In VMware ESX there is a setting on a per VM basis, or on a group of VMs known as CPU Limit. Just like with Memory Limits discussed above, a CPU Limit is imposed on a VM to hold back the amount of processing allowed to the operating system within it. What does this mean for you? Badness. Cats and dogs living together, mass hysteria. Just like the CPU Ready example above, you will experience processing slow downs throughout the day with no apparent rhyme or reason. As is with all of the other obstacles in the arena we’ve discussed, again this time you have no way of detecting this anomaly in Task Manager. You will see CPU percentages in Task Manager hitting 100% when in fact there was plenty more processing power available on the physical host. What can you do?
Hopefully this article empowers you the Windows Admin to take back what is rightfully yours. Happy fans. Fast operating systems. Data available when and where you need it. If you don’t have any luck, start looking at moving your workloads to Windows Server Hyper-V 2012 or to the cloud. You will not find yourself in some game master’s arena in Hyper-V 2012. Give it a spin here! Or you can leave the private virtualization practice altogether, deploy and manage your own virtual machines from a web interface on the fastest collection of hardware on the planet. Windows Azure for Virtual Machines is available now, give it a try here!