Licensing SQL 2012 in a VM with Hyper-threading
When I talk to customers about running SQL in a virtual machine I often refer to the SQL 2012 Licensing Guide to make sure I have the latest information. This document has changed quite a few times over the last year and I often find something new that I didn’t notice in the prior version (or simply wasn’t there).
Last week I was looking at the SQL 2012 Virtualization Licensing Guide (opens a PDF) when I noticed something I hadn’t seen before with regards to using hyper-threading and virtualizing SQL 2012. From the guide:
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 hyperthreading
creates two hardware threads for each physical core, a total of 8 core licenses would be required
in this scenario. A core license allows a single virtual core to be supported by a single hardware thread.
Hard as that is to believe, Microsoft is saying that if you use hyper-threading then you need to license both hardware threads rather than the individual core.
This is only really applicable of if you’re licensing individual VMs rather than the entire server as many organizations do. If you license all cores in a physical server with SQL 2012 Enterprise and maintain Software Assurance then you can virtualize an unlimited number of SQL virtual machines. That is likely to be the preferred licensing model, and in fact Microsoft says as much in the same document:
This is especially relevant for private cloud scenarios with a large number of VMs being moved dynamically between different physical servers, when self-provisioning is enabled, or when hyper-threading is turned on.
I support Microsoft’s move to a per-core licensing model instead of a per-CPU model since I recognize this had to happen eventually. On their decision to make organizations buy extra licenses if they use hyper-threading, though, I’m a bit lost. It’s not as if a hyper-threaded core behaves exactly as a physical core and can provide double the performance. This one makes me scratch my head.
At the end of the day it is likely not very cost effective to license individual VMs (rather than the entire host) with or without hyper-threading in most scenarios so this is probably not a big deal. It’s yet another reminder that if you’re looking to perform any kind of SQL virtualization project, you should strongly consider the SQL 2012 Enterprise with SA license for maximum virtualization rights.
I’ve read the same doc and I was surprised at the insistence of counting threads as cores. From a licensing point of view we are tossing up between physically licensing a physical host or licensing the virtual machines. From a pure administration point of view, licensing the VM is actually simpler as we can just let DRS do its thing and spread multiple smaller SQL VM’s across the cluster rather than less larger VM’s pinned to a single host. It also means we can more easily bill the project when they want another SQL server that they don’t want to share with other apps.