Table 2-1. Hyperthreaded Core Sharing Modes
Option Description
Any The default for all virtual machines on a hyperthreaded system. The virtual CPUs of a virtual machine
with this setting can freely share cores with other virtual CPUs from this or any other virtual machine at
any time.
None Virtual CPUs of a virtual machine should not share cores with each other or with virtual CPUs from other
virtual machines. That is, each virtual CPU from this virtual machine should always get a whole core to
itself, with the other logical CPU on that core being placed into the halted state.
Internal This option is similar to none. Virtual CPUs from this virtual machine cannot share cores with virtual
CPUs from other virtual machines. They can share cores with the other virtual CPUs from the same virtual
machine.
You can select this option only for SMP virtual machines. If applied to a uniprocessor virtual machine,
the system changes this option to none.
These options have no effect on fairness or CPU time allocation. Regardless of a virtual machine’s
hyperthreading settings, it still receives CPU time proportional to its CPU shares, and constrained by its CPU
reservation and CPU limit values.
For typical workloads, custom hyperthreading settings should not be necessary. The options can help in case
of unusual workloads that interact badly with hyperthreading. For example, an application with cache
thrashing problems might slow down an application sharing its physical core. You can place the virtual
machine running the application in the none or internal hyperthreading status to isolate it from other virtual
machines.
If a virtual CPU has hyperthreading constraints that do not allow it to share a core with another virtual CPU,
the system might deschedule it when other virtual CPUs are entitled to consume processor time. Without the
hyperthreading constraints, you can schedule both virtual CPUs on the same core.
The problem becomes worse on systems with a limited number of cores (per virtual machine). In such cases,
there might be no core to which the virtual machine that is descheduled can be migrated. As a result, virtual
machines with hyperthreading set to none or internal can experience performance degradation, especially on
systems with a limited number of cores.
Quarantining
In certain rare circumstances, an ESX/ESXi host might detect that an application is interacting badly with the
Pentium IV hyperthreading technology (this does not apply to systems based on the Intel Xeon 5500 processor
microarchitecture). In such cases, quarantining, which is transparent to the user, might be necessary.
Certain types of self-modifying code, for example, can disrupt the normal behavior of the Pentium IV trace
cache and can lead to substantial slowdowns (up to 90 percent) for an application sharing a core with the
problematic code. In those cases, the ESX/ESXi host quarantines the virtual CPU running this code and places
its virtual machine in the none or internal mode, as appropriate.
Set the Cpu.MachineClearThreshold advanced setting for the host to 0 to disable quarantining.
Using CPU Affinity
By specifying a CPU affinity setting for each virtual machine, you can restrict the assignment of virtual
machines to a subset of the available processors in multiprocessor systems. By using this feature, you can assign
each virtual machine to processors in the specified affinity set.
In this context, the term CPU refers to a logical processor on a hyperthreaded system, but refers to a core on a
non-hyperthreaded system.
The CPU affinity setting for a virtual machine applies not only to all of the virtual CPUs associated with the
virtual machine, but also to all other threads (also known as worlds) associated with the virtual machine. Such
virtual machine threads perform processing required for emulating mouse, keyboard, screen, CD-ROM and
miscellaneous legacy devices.
vSphere Resource Management Guide
20 VMware, Inc.
