Performance with 1xvCPU and 2xvCPU VMs

Posted on 2008-10-16
Medium Priority
Last Modified: 2012-05-05
Hi. I've been reading some info re. running single vCPu and dual/quad vCPU virtual machines on the same ESX host.

I believe that not only can assigning multiple vCPUs to a VM that doesn't really need it can affect performance of other VMs by using CPU cycles that could be used elsewhere, but I've also read that the CPU scheduler in ESX has to work overtime to work out what gets scheduled next when you start mixing VMs with different numbers of vCPUs.

Is this correct, and how much effect does this have in real environment?
Question by:paulo999

Assisted Solution

SecretWeapon earned 150 total points
ID: 22736108
I run a esxi server with 8 CPU and 3servers and 2 xp machines and all VM use only 1 CPU...I have been told that i could have 2 of my servers run 2CPU each and it would still work like a charm....It should work depending on how my CPU your server has total...This in effect will performace of the VM if there are limited number of CPUs......Does that help at all?????

Author Comment

ID: 22736200
Thanks for the comment, SecretWeapon.

I have 160 physical servers that we want to virtualise, ranging from 1 to 4 cores (some are old servers) so I'm really thinking of this from a bigger scale.

If I had say, a DL380 G5 with 2xQuad Core Xeons and 32GB of RAM, running 16 VMs, or maybe a DL580 G5 with say 4xQuad Core Xeons, 64GB of RAM and running 32 VMs, how much would running a mixture of single, dual and quad vCPU machines on the same host affect performance?

If it would affect performance a lot would I be better off splitting my ESX clusters into single, dual and quad core VM clusters? Or maybe look at trying to configure DRS to only allow VMs with the same number of vCPUs to run on the same host (I don't know if the later is actually possible?). Thanks.
LVL 42

Assisted Solution

by:Paul Solovyovsky
Paul Solovyovsky earned 750 total points
ID: 22737080
You should keep the virtual machines at 1 vCPU in most cases, adding additional vCPUs has hurt performance in many instances.  The only time you would want to give more than 1 vCPU is for servers running applications that can take advantage of multithreading such as SQL, and even than i would start with one vcpu and add more if needed (just remember that you'll need to change the Windows HAL) for multiple CPUs if you do this.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.


Author Comment

ID: 22738548
Thanks for that. This is the current method I use - just use one vCPU and only use multiple if there is a specific reason to do so.

Regarding your comments about changing the Windows HAL; I remember on NT 4.0 if you went from one CPU to multiple CPUs you had to manually change the kernel, however with Win 2003 server I've just added the vCPUs and its registered them - am I missing something?
LVL 42

Assisted Solution

by:Paul Solovyovsky
Paul Solovyovsky earned 750 total points
ID: 22739547
check this thread out


I've changed it on the fly and had minimal issues but it may be a good idea to change it.

Accepted Solution

EFHC earned 600 total points
ID: 22744236
When you add a vCPU to a Windows 2003 server it will automatically change the HAL to a multiprocesser ACPI driver. You have to manually change the HAL when you go from multiprocessor down to a uniprocessor (one).
Also the main reason that you do not want to give your VMs more than 1 vCPU is because of the way that ESX schedules CPU Time in the hypervisor. When you have 2 vCPUs for a virtual machine the hypervisor will try its hardest to schedule 2 pCPUs at the exact same time for that VM, even if only 1 vCPU is wanting to run instructions. So what happens if you are running multiple VMs with 1vCPU then can run on any pCPU at anytime, now the VM with 2 vCPUs needs to wait for 2 pCPUs to be available at the exact same time so you will have that VM waiting more to get time on the pCPU. This is by design so that the VM doesn't get messed up because if an application sends instructions to both CPUs and they are ran through the pCPUs at different times you end up getting timing errors and your application will run really bad. This is why you only want to use 2 vCPUs on VMs where the software can truely take advantage of it. We have started moving most of our VMs from 2 to 1 vCPUs because they run better than if they had 2.

Author Closing Comment

ID: 31526339
Well my question was really how much stress is put in the VMWare scheduler when mixing single vCPU and multi vCPU VMs on the same host. But this info is good just the same. Thanks.

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

What if you have to shut down the entire Citrix infrastructure for hardware maintenance, software upgrades or "the unknown"? I developed this plan for "the unknown" and hope that it helps you as well. This article explains how to properly shut down …
In this article will go through how to backup a vPostgres DB from a broken vCenter Appliance and restore to a new vCenter Appliance.
Advanced tutorial on how to run the esxtop command to capture a batch file in csv format in order to export the file and use it for performance analysis. He demonstrates how to download the file using a vSphere web client (or vSphere client) and exp…
This video shows you how easy it is to boot from ISO images for virtual machines with the ISO images stored on a local datastore on the ESXi host.
Suggested Courses

621 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question