Hyper-threading enables the resources of a physical core to be shared across multiple threads or VMs. Accordingly, if a VM was to leverage 100% of all the physical cores on the physical CPU, there would be no surplus CPU resources available to assign to other workloads.
Normally, a VM will ‘burst’ access to the peak available resources for a short period of time, allowing other VMs and to use the physical cores of the host. With hyper-threading enabled, the resource scheduler would not strictly assign resource to a single VM, but can dynamically re-assign resources as required.
For example, on a 4 core CPU, with 4 guest VMs running on the host server, if the workload on each individual VM is only really using one single core, this would mean three cores are sitting idle. While those cores are sitting idle, the processor queue is building up for any other VMs. Alternatively if you assign each VM a single core, you are enabled to schedule all four VMs to run concurrently, and now you’re not wasting three cores by scheduling idle vCPUs on them.
Microsoft Approach to Hyper-Threading
After the release of SQL server 2012, Microsoft sought to capitalize on the advancement in hyper-visor technology pioneered by VMware, by updating the licensing metric for SQL server, and their approach to licensing for hyper-threading technology (HTT). Conversely, under the former licensing model for SQL Server 2008 R2, hyper-threading could make SQL licensing cheaper.
- When resources are scheduled 1:1 with the hardware.. “For licensing purposes, a v-core maps to a hardware thread “
- Microsoft then sought to protect themselves , by stating additional core licenses are requires when:-
- A single hardware thread is supporting multiple vCPUs
- When Multiple hardware threads are supporting a single vCPU simultaneously.
[Ref: SQL Licensing Guide 2017, Page 17 of 36]
As SQL per-core licensing allows a single v-core to be supported by a single hardware thread. I would characterize this broadly as:
- take the number of vCPUs
- or the number of threads available to the VM… whichever is higher.
The Impact of Resource Topology
- If we have a 1:n relationship between hardware thread: vCPU
- (i.e. a vCPU is scheduled on 1 thread, but that thread could schedule multiple vCPU) we have to ensure we have enough core licenses to cover the number of vCPU (with the “minimum of 4” caveat) per SQL VM
- If we have a n:1 relationship between hardware thread: vCPU
- If we were to enable threading (HT) within the VM (which I believe can be done with ESX 5.1 and above)
we would then need to purchase additional licenses as a vCPU would have two v-thread which would/could
be scheduled on separate hardware threads.
- It would have no impact for a VM with 1 or 2 vCPUs, as the minimum licensing requirement is 4 virtual cores per VM.