There’s a fair bit of confusion around licensing SQL that is virtualized and I have been getting questions from customers about this for a long time now. The confusion comes from a few statements in the Microsoft SQL Server 2014 Virtualization Licensing Guide guide which states:
“For customers using Intel’s hyper-threading technology to split a single, physical core into two separate threads of power, there are some additional factors that should be kept in mind when licensing individual VMs using the Per Core Model”
This states that there are special considerations for licensing virtualized SQL servers on a per-core model when Hyper-threading is enabled on the hypervisor host.
What is the per core model, you ask?
The per core model is when licensing the virtual CPUs of a virtual SQL server rather than the physical CPUs on the hyper-visor server. As stated in the doc: “Per Core Licensing Model: Purchase a core license for each virtual core (or virtual processor/virtual CPU/virtual thread) allocated to the VM, subject to a four core license minimum per VM).“
Here is where it get’s confusing, the document states: “When hyper-threading is turned on, a core license is required for each thread supporting a virtual core. In the example below, hyper-threading is enabled for the physical processor supporting a VM. Since hyper-threading creates two hardware threads for each physical core, a total of 8 core licenses would be required in this scenario”
I’ll address the first part of the statement first: “When hyper-threading is turned on, a core license is required for each thread supporting a virtual core”
There is a fundamental error in this statement from a technical perspective, the way it works when assigning a virtual CPU/core to a VM is that it will always be mapped to a single CPU context. A CPU context can be a physical CPU, core or thread.
In vSphere, that virtual core can be migrated at any given time to any other CPU context on the server, but will always be mapped to one, as seen in the following diagram.
The Guest OS (which is Windows in this case) will only “see” the number of cores that was assigned to it, regardless of whether the hyper-threading is enabled on the physical host or not. Therefor in the example above, that VM will see 4 CPUs with 1 core each.
The statement continues and describes the diagram “In the example below, hyper-threading is enabled for the physical processor supporting a VM. Since hyperthreading creates two hardware threads for each physical core, a total of 8 core licenses would be required in this scenario”
In this diagram, we can see a CPU with 4 cores and 8 hyper-threading logical threads, but, we see 2 VMs each with 4 virtual CPUs, so obviously 8 licenses are required in this case. It’s not clear if it’s because there are 2 VMs with 4 CPUs each or because of hyper-threading.
So, the question customers ask, understandably, is when licensing on a per core model and not physical cores, should Hyper-threading be taken into account? and if so how?
That lingering question is the root cause of the confusion. Our interpretation (and guidance to customers) is as follows:
On vSphere, per-core licensing for a virtualized SQL server does not depend on the state of hyper-threading. The overriding considering is the TOTAL NUMBER of virtual CPUs allocated to the SQL Server VM (or VMs).
If In the above examples, there are 4 physical cores on the hypervisor, IF the total number of vCPUs allocated to 1 VM is 4, then the required licenses will be FOUR, even though hyper-threading is enabled on the host.
Common sense says that it shouldn’t because a 4 vCPU’s VM will only “see” 4 CPUs and will only be mapped to 4 CPU contexts no matter if hyper-threading is enabled or not.
I spoke with a few folks at Microsoft which responded unofficially on the subject confirming that hyper threading on the hypervisor’s physical server is of no relevance to the per-core licensing term.
I have yet to receive an official guidance from Microsoft on this matter. I will update this post once I hear back officially from our Microsoft counterparts.
