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.
For example, VMware vSphere has a feature that changes the presentation of logical processors for a virtual machine, into a specific processor and core configuration. This advanced setting is commonly known as ‘coresPerSocket’.
It was originally intended to address licensing issues where some Windows OS had limitations on the number of processors that could be used, but did not also limit core count.
There are therefore two potential resource topology models to consider for the purposes of SQL server licensing.
- Wide and Flat : create a VM that is 4 processors x 1 core (So splitting the work across 4 Processors with 1 Core Each)
- Narrow and Stacked: create a VM with 1 processor x 4 core (matching physical topology). This is more common.
To understand your virtual infrastructure topology, with vCenter for example, you can look at Coreinfo, (which is a command-line utility) that shows you the mapping between logical processors and the physical processor, NUMA node, and socket on which they reside, as well as the cache’s assigned to each logical processor. This uses the Windows’ GetLogicalProcessorInformation function to obtain this information and prints it to the screen, representing a mapping to a logical processor. Coreinfo is useful for gaining insight into the processor and cache topology of your system.
I am not an expert on ESX, but when I have researched this topic, this is how I think VM resources could commonly be scheduled:
Example topology with no Hyper-Threading
If this is based on a 1:1 relationship between vCPUs and hardware threads: example for single CPU below.
|vCores*||4 vCore||4 vCore||4 vCore||4 vCore|
|vCPUs||CPU 0||CPU 1||CPU 2||CPU 3|
|Threads||Core 1||Core 2||Core 3||Core 4|
|Physical||Core 1||Core 2||Core 3||Core 4|
Example topology with Hyper-Threading
|Licensing||4 v Cores||6 v Cores||8 v Cores|
|vCPUs||CPU 1||CPU 2||CPU 3||CPU 4||CPU 5||CPU 6||CPU 7||CPU 8|
|Threads||Core 1||Core 2 (HT)||Core 3||Core 4 (HT)||Core 5||Core 6 (HT)||Core 7||Core 8 (HT)|
|Physical||Core 1||Core 2||Core 3||Core 4|
*Minimum of 4 vCores per VM for Licensing.
So when resources are scheduled 1:1 with the hardware, Microsoft licensing “For licensing purposes, a v-core maps to a hardware thread”. Accordingly, as Microsoft then protect themselves via these caveats, stating additional core licenses are required when:-
- A single hardware thread is supporting multiple vCPUs (Narrow and Stacked)
- Multiple hardware threads are supporting a single vCPU simultaneously. (A core license allows a single v-core to be supported by a single hardware thread.) (Wide and Flat)
So If you as the end-customer would consider that ‘number 1’ applies, and that a single hardware thread is supporting 4 vCPUs, even on a hyper-thread enabled Intel CPU, Microsoft would want you to license 4 virtual cores per individual VM.
When calculating the number of core licenses required, as a core license allows a single v-core to be supported by a single hardware thread. I characterize this broadly as:
- take the number of vCPUs
- or the number of threads available to the VM, whichever is higher.
The general rule is that hyper-threading can often double the number of core licenses required. Notably, this would not apply to VMs with only 1 or 2 vCPUs assigned, as the VMs would still require the minimum of 4 virtual cores from a licensing perspective.
- I have often been asked about technical workarounds, and one approach could be setting up CPU affinity and limit the available CPUs on which the VM can run. This does not dedicate that CPU to that individual VM, and therefore does not restrict the CPU scheduler from using that CPU for other VMs, so this could provide control as to the multiple hardware threads available to support a virtual processor.
- Alternatively, with ‘Hyperthreading Sharing’ on the properties tab of a VM, provides control as to multiple VMs sharing a single hardware thread
- SQL Enterprise with active SA, provides the option to license all physical cores on the host(s) without reference to hyper-threading, and additionally support unlimited SQL VMs
This website is a way to give back to the licensing community and as an information resource for all customers that work with Microsoft software and licensing. I hope you find it of value.
Copyright – Softspend Limited 2019. All Rights Reserved.