Home > Blogs > Virtualize Business Critical Applications

Hyper-threading doesn’t count for virtual SQL licensing

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.

CPU mapping vSphere

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” 

Licensing guide 1

Diagram taken from Microsoft’s SQL Server 2014 Virtualization Licensing Guide http://sql2014.pl/docs/SQL_Server_2014_Virtualization_Licensing_Guide.pdf

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.


This entry was posted in Microsoft, SQL, vSphere and tagged , , , on by .
Niran Even-Chen

About Niran Even-Chen

Niran (@niranec on Twitter) is a Staff SE Specialist in VMware’s Network and Security BU, specializing in NSX and applications.
With over 15 years of experience in IT Engineering, architecture and sales roles.
The technical expertise Niran acquired includes design, technical selling and evangelizing of virtualization, Networking, Storage, performance, Cloud (CNA and Cloud management) and BC/DR solutions.
In his current position at VMware Niran devotes his time in helping Enterprise and global customers in their journey to digital transformation with Developer Ready Infrastructure, focusing on NSX and Pivotal Cloud Foundry Integration.
In his previous positions at VMware Niran was the main SME at VMware for Microsoft SQL Server virtualization and the author of the official best practices guides it, and also a Cloud and Performance specialist.
Niran is a frequent speaker at industry events and conferences including VMworld, VMUGs, SQL Saturdays and more. He is also part of the CTO Ambassador Program at VMware.

14 thoughts on “Hyper-threading doesn’t count for virtual SQL licensing

  1. Dustin Lema

    Microsoft could clear this up very easily if it wanted to. They could change the language to include “this includes hyperthreading”.

    But they have not and will not to get the customers that are weary of upsetting the Microsoft beast and just pay the bill. This intentional (my word) lack of clarity appears to be by design and customer’s will just play it safe.

    But clearly, Hyperthreading should have no bearing on licensing whatsoever.

    1. Niran Even-ChenNiran Even-Chen Post author

      This setting controls whether a VM is backed by hyper-threaded cores or not So to answer your question, the guest OS does not “see” if it’s using a hyper-threaded core.

  2. Mike McGhee

    Thanks for this post. I agree completely with your interpretation and you answered my question on whether it was even possible for a vCPU to map to multiple hardware threads simultaneously.

  3. Vic

    Thanks a lot for this post.

    What is your opinion regarding the following case:

    We have physical ESX host with 2 CPU and 10 core each.
    We have many VMs installed, but only one VM have SQL server 2014 Standard edition.
    We have assigned 4 virtual CPUs to VM running SQL server.

    Do I understand correctly, that in this case only 4 SQL server core licenses are needed and not 20 (2 CPU x 10 cores)?

    1. Niran Even-ChenNiran Even-Chen Post author

      Sorry for the late response here, the system failed to send me an email about this. As for your question, yes, if you allocate 4 CPUs to the VM and license per core than 4 licenses are required.

  4. Aredhel

    Hi there,

    Thank you so much for this article. Those statements from MS is confusing me and the server team. I had wondered why hyper threading play a role in virtual licensing. This makes more sense and when I asked MS it appears they’re don’t even know how to make sense of their statements.

    Does this apply to just VMWare or pretty much any virtualisation?

    1. Niran Even-ChenNiran Even-Chen Post author

      MS policies for virtualiztion apply to all virtualization platforms that are supported by Microsoft. My expertise lies with vSphere so from a technical perspective I know how our platforms works

  5. Guy

    Just walking in to this minefield myself. So if I have a box with 2 x 4 core CPUs hyperthreaded (ESXi says 16 logical processors) and I have 8 x SQL2014 core licenses does that mean I’m only using half of the horsepower in the box?

  6. Joel Janke

    I think you are missing where the rub is vic. If i have a 4 cpu x 8 core box, so 32 hardware cores (and thus 64 processing threads) and I virtualize this and put a 48 virtual cpu and 16 virtual cpu box on top, how many SQL Server core licenses due I need? If I want to pretend that threads do not matter then the answer is 64 (48 + 16). If I understand that threads do matter, however, as there is a provision that allows me to license the entire underlying hardware per core (not per thread), then the answer is only need 32 SQL Server core licenses cutting my costs in half. Would you not concur?

  7. Jon

    If I create a hyper v VM with 10 cores.

    The server is a windows 2012 r2 2x processors with 10 cores each
    20 cores total, 40 threads.

    I am creating a vm for sql I would like that vm to use 10 cores/threads ( not sure the difference in hyper v they call it processors.

    My question is if I buy sql 2016 standard 16 core can I install it on the vm with 10 cores or so I need to up the vm to have 16 cores.

    I want to install sql 16 core on a vm with less cores….

    Can’t figure out what to do and want to know before I buy

    1. Deji

      @Jon, I assume that you are talking about doing this on VMware vSphere, not Hyper-V 😉

      You do NOT need to allocate 16 cores to the VM just because you have the capability to use 16 cores. On vSphere, the OS and application inside the VM will see only the number of virtual CPUs (vCPUs) that you have allocated to the VM. The version of SQL you are talking about lets you “use up to” 16 cores, it doesn’t REQUIRE you to use 16 cores. If you like, you can give it only one core (vCPU) and SQL wouldn’t care. Well, it would care because it will likely be slow and you are likely wasting money in the process, but I think you get the idea 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *