What should the ESXi VM CPU settings be on a hyperthreaded server?

[IT_Architect]

What should the VMware ESXi VM CPU settings be on a hyperthreaded server?

I read the hyper-threading section at http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf.  It states:

"Unlike having twice as many processor cores — that can
roughly double performance — hyper-threading can provide anywhere from a slight to a significant
increase in system performance by keeping the processor pipeline busier."

it goes on to say:

"An ESX system enabled for hyper-threading should behave almost exactly like system without it. Logical
processors on the same core have adjacent CPU numbers, so that CPUs 0 and 1 are on the first core, CPUs
2 and 3 are on the second core, and so on."

Logic:

For VMware ESXi on hyper-threaded servers, what logically follows in my mind is:

1.  If a VM requires the power of 2 cores, I must specify 4 CPUs in the VM settings.

2.  It is never efficient to not assign any number of CPUs that is not an even multiple of 2.  Thus, the minimum number of CPUs in the VM settings should be 2.

3.  Server planning, with regards to the number of cores required to support the VMs and system, remains the same for both hyper-threaded and non-hyperthreaded servers.  However, deploying on the hyper-threaded server requires doubling the CPU count in the VM settings to retain performance similar to a non-hyperthreaded server, and to leverage the benefits of hyper-threading.

4.  When I ssh into the OS and see CPU 0, 1, 2, and 3, CPU 0 and 1 are the first core, and CPU 2 and 3 are the second core.

Question:

Is this logic correct?

[AWo · Accepted solution]

Logic:

For VMware ESXi on hyper-threaded servers, what logically follows in my mind is:

1.  If a VM requires the power of 2 cores, I must specify 4 CPUs in the VM settings.

No, one vCPU get's scheduled to one core, either directly or when Hyperthreading is enabled (which the guest OS doesn't know, but ESX does) via a logical processor generated by Hyperthreading. So if you want the guest to use two cores, assign two vCPU's.

2.   It is never efficient to not assign any number of CPUs that is not an  even multiple of 2.  Thus, the minimum number of CPUs in the VM settings  should be 2.

The minimum number should be one vCPU. Without this vCPU there's no guest. In fact, you should start with one vCPU whenever possible and only increase the number when you have a good reason or really see a performance gain. That is due to the fact that ESX needs to wait for the appropriate number of free cores until it can schedule work from a SMP guest. So if the guest has two vCPU's it needs two free cores. First it has to wait for these cores to become free (that slows down the guest) and then it occupies two cores (which might slow down the other guests depending on the number of available cores). If Hyperthreading is enabled, ESX can schedule the work faster but the actual processing still can only be done by a physical core. Since ESX 4 there are better SMP scheduling mechanisms but these restrictions still apply in general. (http://communities.vmware.com/message/1692107#1692107)

3.  Server planning, with regards to the number of cores required to support the VMs and system, remains the same for both hyper-threaded and non-hyperthreaded servers. 

Yes.

However, deploying on the hyper-threaded server requires doubling the CPU count in the VM settings to retain performance similar to a non-hyperthreaded server, and to leverage the benefits of hyper-threading.

No. Hyperthreading either is neutral, that means it doesn't affect the perfomance negatively or it increases the performance slightly due to the faster scheduling (not processing!).

AWo

[J1mbo]

To add to the already pretty thorough detail above, think of it in the terms that ESX will attempt to schedule on cores directly unless there aren't enough to go round, then it will utilise logical cores (i.e. HT) to help things along.

HT enables the CPU to switch to another waiting thread whilst it would otherwise be stalled waiting (for example, for a memory read).  So in that sense HT helps the CPU keep working at capacity, rather than adding capacity per-se.

[IT_Architect]

Thank you all for clarifying this.