When I did those, I then got the following alarm: ESX.Problem.Hyperthreading.Unmitigated all 6 of the servers are M4's. But when I go to the Advanced system settings, only the 3 new servers have this as an option to set to true or false (Currently set to false). A host that is enabled for hyperthreading should behave similarly to a host without hyperthreading. You might need to consider certain factors if you enable hyperthreading, however. ESXihosts manage processor time intelligently to guarantee that load is spread smoothly across processor cores. Upgraded one of our ESXi hosts with the latest patches released today that are aimed at fixing the L1 Terminal Fault issues. After that the host started giving this warning: esx.problem.hyperthreading.unmitigated. Hyperthreading technology allows a single processor core to execute two independent threads simultaneously. While hyperthreading does not double the performance of a system, it can increase performance by better utilizing idle resources leading to greater throughput for certain important workload types.
Anyone that virtualized Exchange server in recent years had stumbled into this conundrum: should I disable Hyperthreading on the physical server or not?
The main cause of this confusion is conflicting recommendations coming from Microsoft and VMware on the subject, I am happy to say that this debate is finally over. As we at VMware have been saying all along, there is no need to disable Hyperthreading when virtualizing Exchange server; that recommendation was suitable only for physical servers and is irrelevant for virtual machines.
In some of their Exchange server best practices and sizing guides, Microsoft had specifically asked customers to disable Hyperthreading without making the distinction between physical and virtualized servers, this recommendation was made for two main reasons (according to Microsoft)
- When enabling Hyperthreading Exchange “sees” the “extra” logical cores and will allocate heap memory to them even though these are not actual physical cores, resulting in unnecessary memory waste.
- Another argument to disable Hyperthreading was that Microsoft didn’t want to confuse IT professionals that are sizing Exchange deployments into thinking they have more physical cores than they actually have because of Hyeprthreading.
Throughout the years, we have told our customers the opposite:, enable Hyper threading as this will increase CPU efficiency on the physical server resulting in more resources for virtual machines.
We have steadfastly contradicted Microsoft on this specific subject because virtual machines on vSphere are not aware of the extra logical CPU’s and “see” only the amount of virtual CPUs it’s been allocated by the hypervisor. The second rationale for our disagreement with Microsoft over the years is that disabling hyper-threading in a virtual environment unnecessarily removes a very valuable performance improvement feature of virtualization. We know that our hypervisor (vSphere) benefits greatly from hyper-threading and we were unaware of any engineering defects in this feature.
As for the second reason Microsoft had previously gave for disabling Hyper-threading, we simply told our customers to make sure they consider only the physical cores in the physical server when they are conducting sizing exercises.
For our official guidance on the subject see the “Hyper-threading” section of our most current Exchange Server Best Practices Guide -(https://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Best_Practices_Guide.pdf)
In a recent blog post from the MS Exchange team titled “What’s The Story With Hyperthreading and Virtualization?“ Microsoft guides customers to make a distinction between physical and virtual Exchange servers on the subject of Hyper-threading based on the reasons I detailed above, saying: “The guest VMs do not see the logical processors presented to the host, so they see no difference in processor count when Hyperthreading is turned on or off”
Adding also “If you have a virtual deployment, you can enable hyperthreading (best to follow the recommendation of your hypervisor vendor).”
The previously released official sizing guide for Exchange 2013 was updated this past January with similar guidance.
Vmware Kb Esx.problem.hyperthreading.unmitigated
Vmware Hyperthreading Mitigation
We are glad that Microsoft is clarifying its documentation and clearing up the confusion for our joint customers.