9

To my understanding, virtual machines (assuming Relative Weight is equal) get an equal share of the processor.

When the VM is given some processing time, it shouldn't matter if the VM is seeing a single core for it to use or multiple cores, since the processing comes out of an array of processors on the Hyper-V host regardless. However, when I set the Number of logical processors setting from 1 to 4 in Hyper-V for a particular VM, I see a huge performance increase.

Specs on my current setup are approximately:

  • Hyper-V host has 32 GB RAM, 24 logical processors (wrong word?), a few TB of space.

  • VMs are allocated 6 GB RAM, 1 or 4 cores, a few hundred GB of space and running 2008 R2.

I've experienced a similar thing on past Hyper-V setups.

2 Answers 2

20

Virtual machines in every hypervisor that I know of are able to use additional virtual CPUs on which to schedule additional concurrent threads of execution.

It's exactly that layer of abstraction between physical machine and virtual machine that makes it not work the way you describe. The VM is not aware of how many cores the physical machine has. The VM does not "see" the physical CPUs (or cores) on the physical machine. The hypervisor gives the VM how ever many virtual CPUs, and the guest OS uses those virtual CPUs to schedule additional concurrent threads... The total number of virtual CPUs the hypervisor hands out to the virtual machines can even exceed the number of physical CPUs/cores in the machine.

Said another way, a virtual machine, when assigned a single vCPU, schedules its threads as if it only had one CPU. It doesn't matter how many cores are in the underlying physical machine. (Though it is worth noting that the physical machine may schedule that one VM thread on one physical core for one thread quantum, or time slice, and then run it on a different physical core the next time it's scheduled to run. The virtual machine has no idea any of that is happening though. All it knows is that it can only schedule one thread at a time, one after the other, because it only has one virtual CPU.)

And let's be very clear about our terms here. You assign vCPUs, or virtual CPUs, to VMs, not "cores". Cores (by which I assume you mean physical processing units that share a single physical socket) do not equal vCPUs. There is a layer of abstraction between them. If a VM only has 1 vCPU assigned to it, it can only schedule one thread to run at a time. That is why your VM runs faster with 2 -4 virtual CPUs assigned to it - because it is now able to schedule more than one thread to run concurrently.

However, there is definitely a law of diminishing returns here, as an excessive number of virtual CPUs incur a higher and higher overhead cost in things like synchronization, etc.

There are slight differences between how Hyper-V and VMware hypervisors schedule virtual machine threads for execution, and they differ in their approach to physical resource "oversubscription," but this is a good general concept to start with.

10
  • 7
    @Flapjack00 No... that's the exact opposite of what I just said. And let's be very clear about our terms here. You assign vCPUs, or virtual CPUs, to VMs, not "cores". Cores (by which I assume you mean physical processing units that share a single socket) do not equal vCPUs. There is a layer of abstraction between them. If a VM only has 1 vCPU assigned to it, it can only schedule one thread to run at a time.
    – Ryan Ries
    Jul 23, 2013 at 18:53
  • 1
    Ah! So, in that case, a VM configured with 4 vCPUs could schedule 4 threads at a single time. Assuming my host has enough vCPUs available, those 4 threads could be processed at the same time? Jul 23, 2013 at 18:58
  • 1
    @Flapjack00 "Assuming my host has enough vCPUs available" - The host does not have vCPU's, the VM does. The host has cores (or, more correctly, logical processors - a single core may have multiple logical processors, like with Hyper-threading) which vCPUs get assigned to.
    – BlueRaja
    Jul 23, 2013 at 21:46
  • 2
    @Dan, that's an issue specific to VMware. It doesn't affect Hyper-V. Jul 23, 2013 at 21:56
  • 1
    The "x vCpu require Y cpu locks" that VMware had was removed in ESX 3.5, so this doesn't really apply to any modern hypervisor anymore. That being said, you should be careful about not assigning unneeded resources to your VMs, and vCpu's are especially important. Too many of them and you'll lose performance overall.
    – pauska
    Jul 24, 2013 at 8:27
3

The amount of assigned virtual CPUs does matter. The software running in the VM is not aware of the fact it's in a VM and that the host is capable of more than what the VM is presented. So if you are running software that can take advantage of multiple CPU cores, in a VM that only has one core assigned, the software will only schedule one core for its tasks, and the VM as well, will only be using one host core at a time. Once you give the VM more cores, the software can schedule more parallel tasks, which the hosts' CPU will schedule for the VM.

Be careful not to give VMs too much, so as not to cause contention, if one VM has more virtual cores than the host does, the VM will be contending against itself, and in case of gang scheduled hypervisors, like vmware, the VM will never be able to execute anything at all (the option to overallocate is blocked by the management layer of course).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .