VMware ESXi and vSphere Cluster Management

Enable and Verify Hyper-Threading on VMware ESXi

Learn how Intel Hyper-Threading works in VMware ESXi, enable it in BIOS or UEFI and ESXi, verify CPU topology, and safely roll back the change.

Intel Hyper-Threading is a form of simultaneous multithreading (SMT). It allows one physical CPU core to expose multiple hardware threads, called logical processors, to VMware ESXi. ESXi can schedule work on those logical processors, but sibling threads still share execution resources inside the same physical core.

Understand CPU topology and Hyper-Threading

A physical CPU package is a processor installed in a server socket. A package contains one or more physical cores. Each physical core can expose one or more logical processor threads. With Intel Hyper-Threading enabled, a core commonly exposes two logical processors.

Term	What it represents	Relationship to Hyper-Threading
Physical CPU package	A processor socket installed in the server.	A package contains physical cores.
Physical core	An independent processing core inside a CPU package.	One core can expose multiple hardware threads.
Logical processor	A hardware thread that ESXi can schedule.	Several logical processors can belong to one physical core.
Sibling thread	A logical processor sharing a physical core with another logical processor.	Siblings share portions of the core's execution resources and cache.

For example, a server with two sockets, 16 physical cores per socket, and two threads per core has this theoretical topology:

2 sockets × 16 cores per socket × 2 threads per core = 64 logical processors

With Hyper-Threading disabled, the same server normally exposes 32 logical processors. The additional 32 logical processors are not equivalent to 32 additional physical cores. They provide extra scheduling opportunities while sharing resources with sibling threads.

Hyper-Threading is Intel's implementation of SMT. Comparable AMD SMT behavior should be evaluated separately and verified against the applicable AMD platform, firmware, and ESXi documentation.

Performance and capacity implications

Hyper-Threading can improve host throughput when one thread leaves execution resources idle that a sibling thread can use. The benefit depends on CPU contention, cache usage, instruction mix, workload parallelism, and application behavior.

It does not turn one physical core into two fully independent physical cores.
Virtual machines can be scheduled onto logical processors, increasing apparent scheduling capacity.
Logical processor counts should not be used as a direct substitute for physical-core performance when sizing workloads.
Some latency-sensitive or heavily CPU-bound workloads gain little and can occasionally perform worse because sibling threads compete for shared resources.
Admission decisions, capacity planning, and VM sizing must account for the difference between logical processors and physical cores.

After enabling the feature, monitor host CPU usage, CPU ready time, application latency, and throughput. CPU ready time is the time a virtual machine is ready to run but waiting for ESXi to schedule it. Hyper-Threading does not remove the need to size vCPUs carefully or configure reservations, limits, shares, resource pools, and NUMA placement appropriately.

Requirements and pre-change checks

Check	Why it matters	How to verify
Processor and server support	ESXi cannot expose unsupported hardware threads.	Check the processor specification and server vendor documentation.
Firmware option	The server must expose sibling threads before ESXi can use them.	Review BIOS or UEFI documentation for Hyper-Threading, Logical Processor, Intel SMT, or a vendor-specific name.
ESXi version and hardware compatibility	Firmware and hypervisor support must be compatible.	Check the platform's supported firmware and ESXi versions.
Management access	The change can be made through vCenter or the standalone Host Client.	Confirm vSphere Client or ESXi Host Client access and appropriate permissions.
Maintenance window	Firmware and boot-setting changes normally require a reboot.	Plan VM evacuation, maintenance mode, and host downtime.
Baseline topology	A baseline makes validation possible.	Record socket count, physical cores, threads per core, and logical processor count.
Policy review	Performance, licensing, support, and security policies may affect the decision.	Obtain approval and check organizational SMT guidance.

If the host runs virtual machines, plan to migrate them to other hosts or shut them down according to your maintenance procedure. A host in maintenance mode is prepared for maintenance after its workloads have been evacuated or otherwise handled safely. Review ESXi host maintenance mode procedures if they are part of your operational process.

Enable Hyper-Threading in server firmware

Schedule an approved maintenance window and evacuate the host as required.
Restart the physical server.
Enter the server's BIOS or UEFI configuration interface.
Open the processor, CPU configuration, or performance section.
Locate the threading option. Common names include Hyper-Threading, Logical Processor, Intel SMT, or a vendor-specific equivalent.
Enable the option, save the firmware configuration, and restart the server.

The exact menu location and name vary by server manufacturer and firmware release. Firmware support must be active before ESXi can expose sibling logical processors.

Enable the ESXi Hyper-Threading boot setting

The ESXi VMkernel boot setting controls whether ESXi uses supported Hyper-Threading capability. The relevant parameter is VMkernel.Boot.hyperthreading.

Using the vSphere Client through vCenter

Select the ESXi host.
Open Manage, then Settings.
Open Advanced System Settings.
Locate VMkernel.Boot.hyperthreading.
Edit the value and set it to enabled, using the Boolean value accepted by your ESXi release, commonly TRUE.
Apply the change and reboot the host during the planned maintenance window.

Using the standalone ESXi Host Client

Sign in directly to the host's ESXi Host Client, open the host's management or configuration settings, and locate the advanced system settings. Search for VMkernel.Boot.hyperthreading, set it to the enabled value accepted by that release, save the change, and reboot the host. Labels can differ between Host Client versions, so use the parameter name rather than relying only on menu wording.

Using ESXi Shell or SSH

Use command-line access only when it is permitted by your security policy. First query the current value:

esxcli system settings kernel list -o VMkernel.Boot.hyperthreading

To enable the parameter:

esxcli system settings kernel set -s VMkernel.Boot.hyperthreading -v TRUE

Use the exact accepted Boolean value for the installed ESXi release. A reboot is normally required before a boot-setting change affects the host's CPU topology.

Validation after reboot

Stage	Action	Expected result	Reboot required
Firmware	Enable the processor-threading option.	The firmware reports the feature as enabled.	Yes
ESXi setting	Set VMkernel.Boot.hyperthreading to enabled.	The configured boot parameter shows the enabled value.	Normally yes
Host reconnect	Wait for the host to return to vCenter or the Host Client.	The host reconnects without configuration errors.	Already completed
Topology	Inspect host CPU and processor information.	The logical processor count matches the expected topology.	No additional reboot
Workload test	Run representative workloads and compare baseline metrics.	Performance and latency remain within the approved target.	No

In the vSphere Client, inspect the host's hardware, processor, or CPU topology view. Confirm the reported logical processor count and, where displayed, threads per core and physical cores per socket.

For command-line inspection, use:

esxcli hardware cpu list

Review the output for logical CPU identifiers and relationships among package, core, and sibling threads. Then confirm the boot parameter again:

esxcli system settings kernel list -o VMkernel.Boot.hyperthreading

Compare the observed count with this calculation:

logical processors = sockets × physical cores per socket × threads per core

For the example dual-socket host with 16 cores per socket and two threads per core, the expected enabled count is 64 logical processors. The non-threaded count is normally 32 logical processors.

Operational guidance

Place the host in maintenance mode before a planned reboot when it runs virtual machines.
Resolve migration blockers such as affinity rules, local resources, or insufficient cluster capacity before starting maintenance.
Measure baseline application latency, host CPU use, CPU ready time, and throughput before changing the setting.
Repeat the same representative workload after enablement rather than judging the result from logical CPU count alone.
Review vCPU sizing, reservations, limits, shares, resource pools, and NUMA placement. Hyper-Threading does not compensate for an oversized VM or poor locality.
Retain a rollback plan and document the before-and-after topology.

For broader host administration context, see basic ESXi configuration and VMware ESXi administration topics.

Disable and roll back the change

If testing shows unacceptable regression, or policy requires SMT to be disabled, reverse the change in a controlled maintenance window:

Measure and record the affected workload's behavior.
Evacuate the host and enter maintenance mode.
Set VMkernel.Boot.hyperthreading to the disabled value, commonly FALSE, through the client or ESXi Shell.
If required by policy or platform behavior, enter BIOS or UEFI and disable Hyper-Threading, Logical Processor, or the applicable SMT option.
Save the firmware change and reboot the host. Changing either layer normally requires a reboot.
Confirm that the host reconnects, the logical processor count returns to the expected non-threaded topology, and workloads remain healthy.

Troubleshooting

Symptom	Likely cause	Verification	Corrective action
The setting is not visible or cannot be enabled in ESXi.	Unsupported CPU, disabled firmware option, different vendor name, or unsupported firmware/ESXi combination.	Check processor capability, BIOS or UEFI settings, and compatibility documentation.	Enable the correct firmware option or update only to supported firmware and ESXi versions.
The ESXi setting is enabled but the logical count does not increase.	Firmware remains disabled, the host was not rebooted, the topology calculation is wrong, or platform policy limits exposed threads.	Run `esxcli hardware cpu list` and inspect firmware topology.	Correct firmware, reboot, and compare sockets, cores, and threads per core.
A workload performs worse.	Sibling threads contend for execution or cache resources; VM sizing or NUMA placement may also be unsuitable.	Compare latency, throughput, CPU ready time, vCPU count, and NUMA behavior with the baseline.	Right-size the VM, tune resource settings, test in a controlled window, or roll back.
The host cannot be rebooted immediately.	VMs have not been evacuated, or maintenance mode is blocked by rules or cluster capacity.	Review migration tasks, affinity rules, local resources, and available destination hosts.	Resolve blockers, migrate or shut down workloads, and use an approved maintenance window.
Security policy requires SMT to be disabled.	The organization's risk assessment does not permit shared-core sibling threads.	Consult the approved security baseline and current platform guidance.	Disable the required firmware and ESXi layers, reboot, validate capacity, and document the change.

Limitations and security considerations

Hyper-Threading availability depends on the processor, server firmware, platform configuration, and ESXi support. Sibling logical processors share parts of a physical core, which can matter for workload isolation and CPU side-channel mitigation policies.

Follow current VMware, Intel, server-vendor, and organizational security guidance when deciding whether SMT should remain enabled. A security policy may require disabling SMT even when enabling it would improve aggregate throughput.