.shock - Fotolia
Hyper-threading offers a number of performance-based benefits when used in a hypervisor, as it taps into unused processor resources, allowing processors to stay busy and accomplish more. However, the success or failure of hyper-threading within a hypervisor hinges upon whether or not the hypervisor or operating system can detect the hyper-threading technology. Certain hypervisors, such as VMware vSphere, are more successful at this than others. Let's take a closer look at some of the things administrators should take into consideration before introducing hyper-threading to their hypervisor.
Q. What considerations are involved in hyper-threading within a hypervisor?
Hypervisors like VMware vSphere 6 generally do an effective job of recognizing a hyper-threaded processor and scheduling processor time in order to intelligently organize the allocation of workload threads. This is crucial because hyper-threading is basically a means of utilizing free -- unused or underutilized -- processor execution resources; hyper-threading doesn't provide free processors. If the hypervisor winds up trying to place demanding workloads on two logical processors located on the same physical core, both workloads may suffer severe performance penalties. With this lack of hypervisor or OS insight, it would probably be better to just turn hyper-threading off and place each workload on a different physical core. Alternatively, you could provision multiple cores that haven't been hyper-threaded -- multicore -- to the workload in order to multiply the available processor resources.
Hyper-threading technology (HTT or HT) typically employs consecutive CPU numbers, so CPU 0 and CPU 1 are on the first core, CPU 2 and CPU 3 are on the second core, CPU 4 and CPU 5 are on the third core and so on. Hypervisors like VMware ESXi will generally schedule VMs on different cores instead of the same core. If one logical processor is idle, it can be halted to allow the other logical processor on the same core to use all of the processor's execution resources. A hypervisor can see these halt states and track the utilization of each logical processor.
The real wrinkle in workload scheduling is with CPU affinity preferences. Administrators can bind VMs to vCPUs. But if two demanding workloads are bound to logical processors on the same core, the same performance problems can arise with either -- usually both -- workloads because the underlying physical core cannot meet the total processing demands of both threads. System administrators must pay close attention to CPU affinity settings and ensure that any affinity selections are appropriate for the workloads in a hyper-threaded processor.
And don't overlook the actual processors available in the servers. Almost all modern server-class processors support hyper-threading. For example, processors based on Intel's Xeon 5500 architecture, Intel Pentium 4 HT-enabled, Intel Pentium EE 840 HT-enabled and later processor models should handle hyper-threading. However, virtualized servers must also use processors that are suited for the hypervisor.
As hypervisors evolve, older processors may no longer be suitable because those older processors lack certain features and functionality required by the hypervisor -- which may have nothing to do with hyper-threading. For example, older AMD processors including the Opteron 12xx series, Opteron 22xx series and Operton 82xx series are not supported for VMware vSphere 6 -- it will not install. This means it's important to check the system requirements before enabling hyper-threading or installing/upgrading a hypervisor.
The relationship between server configuration and hypervisors
Tips for improving vSphere performance
Don't waste processor resources with overprovisioning
Dig Deeper on Server hardware and virtualization
Related Q&A from Stephen J. Bigelow
Get to know VMware vSphere's Admission Control tool and use it to reserve the resources necessary for VM failover with cluster resource calculations ... Continue Reading
Use heartbeats, VM monitoring and application monitoring to fully examine the causes of VM unresponsiveness. Adjust sensitivity levels to focus on ... Continue Reading
Combine Distributed Resource Scheduler and vSphere High Availability to design balanced failover clusters. Pay attention to affinity rules, which can... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.