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.
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!).
1 person found this helpful
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.
Thank you all for clarifying this.