Everyday Virtualization

Blog archive

5 Big Considerations for vCPU Provisioning

When provisioning virtual machines, either from a new build or during a physical-to-virtual conversion, questions will always come up on how many virtual processors to assign to the host. The standing rule is to provision specifically what is required in order to allow the hypervisor to adequately schedule resources on each virtual machine. The vCPU scheduling is effectively managing simultaneous streams of virtual machines across all available physical CPU cores. A two-socket, four-core server running a hypervisor would provide up to eight cores available at any time. At any time, a number of scenarios could happen including the following:

  • One virtual machine with eight vCPU requests processor time and it is permitted.
  • Four virtual machines, each with one vCPU, request processor time; and it is permitted with four idle cores.
  • Four virtual machines, each with four vCPU, request processor time; and two of them are permitted while the other two are put into a CPU-ready pattern in ESX or ESXi if all four need CPU cycles from each virtual machine. If the sum of vCPU cycles is less than 8, all virtual machines can be accomodated.

The CPU-ready pattern (which should really be called wait) is not a desired outcome. Here are five points that I use in determining how to provision vCPUs for virtualized workloads:

  1. Start with application documentation. If the application says it needs one processor at 2.0 GHz or higher, then the virtual machine would have one vCPU.
  2. Do not apply MHZ limits. The ultimate speed limit is that of the underlying physical core. I came across this great post by Duncan Epping explaining how establishing frequency limits may actually slow down the virtual workload.
  3. Downward provision virtual machines during P2V conversion. The P2V process is still alive and well in many organizations, and current hardware being converted may enumerate four, eight or more vCPUs during a conversion. Refer to the application requirements to step them down during the P2V conversion. Also see my Advanced P2V Flowchart for a couple of extra tips on provisioning virtual machines during a P2V.
  4. Start low, then go higher if needed. If the application really needs a lot of processor capacity, it should be well-documented. If not, start low. The process to add processors is quite easy, but in many cases the system needs to be powered off. Hot-add functionality can mitigate this factor, but only a limited number of operating systems are ready to go with hot-add currently.
  5. Keep an eye on CPU ready. This is the indicator that virtual machines are not getting the processor cycles they are configured for. This can be due to over-provisioned virtual machines crowding the scheduler, or simply too many vCPUs stacked into the infrastructure. ESXTOP is the tool to get this information interactively, and a third-party management product can centralize this data.

Provisioning for vCPUs is one of the more artistic aspects of infrastructure technologies. The hard fact tools are there, but how you craft your infrastructure's vCPU standards will impact the overall performance of the environment.

What tips do you have for provisioning vCPU? Share your comments here.

Posted by Rick Vanover on 05/20/2010 at 9:34 AM


Reader Comments:

Fri, May 21, 2010 Rick Vanover http://rickatron.us

Yes, 8 vCPU isn't exactly good news in a sense. I'm provisioning those marbles very cautiously.

Thu, May 20, 2010 Sean Clark http://seanclark.us

No worries. Love the new URL by the way. :) Here's the link to that CPU Scheduler doc I mentioned earlier: http://www.vmware.com/files/pdf/perf-vsphere-cpu_scheduler.pdf. It took me a good part of a morning last week to wrap my head around the content. It's been worth it as I work towards understanding best practices for 8-proc VMs.

Thu, May 20, 2010 Rick Vanover http://rickatron.us

Doh! Sean, thanks a bunch. I'll get that corrected.

Thu, May 20, 2010 Sean Clark http://seanclark.us

Rick, The scheduling of the VMs is assuming strict co-scheduling which hasn't been used since ESX 2.5. ESX 3 and beyond use relaxed co-scheduling which will allow single vCPUs of multi-vCPU VMs to be scheduled. So a 4 proc VM can really have any combo of 1,2,3,4 vCPUs scheduled when physical cores become available to take work. Only when absolutely required by the guest OS will vCPUs be co-scheduled. I have a great doc on this but not sure if it is for public reading or not. Will did up. So in the 4 X 4vCPU example above, it is possible that all 4 VMs could be running portions of their vCPUs simultaneously. Other than that small point, I still completely agree with the best practices laid out above. Although co-scheduling is smarter, the multiple vCPUs of a VM still have to stay relatively close together in their execution increasing chances for contention on the CPU.

Add Your Comment:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above