About the number of vCPU

[Iwawa]

Hi to All,

I've always doubts about the correct allocation of CPUs and cores per socket to the VMs.

I'll explain better with an example.

Assuming that my Esxi server has two CPUs each with 10 cores and to have 5/6 virtual machines used for various purposes (Windows DC, Development, Production, Services etc), how to allow CPU and Cores for Socket to each virtual machine in order to get the best performance?

Is there a rule or a tool that can help me choose the best solution?

Thank You and Best Regards.

Gaetano

[daphnissov · Accepted solution]

The only available answer here is "it depends" because it truly does. There's no magic formula here other than to assign resources (start at one vCPU) and monitor performance using a tool like vROps. If the workload is using those resources, increment up until the workload is stable.

[RickVerstegen]

Start off with the minimum and add additional when required.

1 vCPU, requests are processed quickly

Multiple vCPU’s, the hypervisor CPU scheduler must wait for physical CPU’s to become available Over allocation could result in poor performance.

The rule of thumb when allocating CPU’s to a Virtual Machine (Best Practice) is to allocate 1 vCPU and then test the CPU utilization. When adding Multiple CPU’s you will need to plan your resources better. vROps can provide utilization stats showing possible performance issues.

[Iwawa]

Thank You for reply

[Dave_the_Wave]

I'd like to add to the "Correct Answer".

I too have asked this long ago, and I came to this realization.

Ideal would be to match up a 1:1 ratio for physical core to a vCPU.

Consider a physical box host with a pair of processors that supply 12 cores, it would be fair to create 12 VM's of 1 vCPU each and resell them to 12 clients on the feature of a dedicated "cpu" for their VM server.

I don't think pruning VM's will make the host "faster". Creating less than the 12 VM's would not really make each remaining VM "better" (by much, please do keep reading).

Remember, the whole point of hypervising is quite the opposite. The reality is that we do get away with creating a lot more than the 12 VM's on that host with no or little performance loss, on the assumption that each VM won't red line itself all of the time. Consider simple web servers that will idle most of the time.

Another way to look at it is thin vs. thick disks. Thick disking reserves the drive space even if it isn't being used. The same can be said for the total of vCPU not to exceed the cores on its host.

(There's also the topic of hyperthreading, which all happens at the hardware level, but we should not see that as double the cores.)

This post is related:

https://communities.vmware.com/message/2736897?tstart=0#2736897

[Iwawa]

Hi Dave

Let's see if I understand correctly.

If I have a host with 2 phisical processors and a total of 12 cores, I can create a maximum of 12 vm assigning to each 1 CPU without losing performance.

It's correct?

[Dave_the_Wave]

Right, the VM isn't supposed to bleed into the others.

If one VM were to red line, Process Affinity will take care of it and isolate that busy VM to just one core.

Don't use hyperthreading into the equation. It helps but HT isn't dual core. So if your 12 core host reports 24 logical processors, it still and always have had 12 cores.

Like I said, if those VMs are going idle and sleep most of the time, it's safe to exceed the vCPU to the cores. On the 12 core host, it would be fine to make 18 VMs or perhaps more. This is the crux of hypoervising.