Exchange Microsoft

The debate about disabling Hyperthreading in virtualized Exchange server is over

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)

  1. 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.
  2. 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.

We are glad that Microsoft is clarifying its documentation and clearing up the confusion for our joint customers.