The Problem with Windows Server 2016 Licensing

Windows Server 2016 is now licensed by the core, but that’s not really the big problem. The bigger problem is buried in the licensing guide (PDF):

  • “A minimum of 16 core licenses is required for each server.”
  • “A minimum of 8 core licenses is required for each physical processor.”

When most sysadmins see that, they’ll think, “Okay, so I shouldn’t bother buying a server smaller than 2 8-core processors.”

But here’s the problem – SQL Server’s licensing guide (PDF) says:

  • “A minimum of four core licenses are required for each physical processor on the server.”

For years, we’ve been teaching DBAs to buy the bare minimum of cores necessary in order to run their workloads. At around $2K USD per core for SQL Server Standard Edition, and $7K for Enterprise, you want as few cores as you can get.

If your sysadmins buy hardware without knowing about SQL Server’s license costs, you might be doubling your licensing costs right out of the gate by buying 8-core processors you don’t need. You’re going to have to educate your sysadmins that yes, we’re going to be throwing away a little money on Windows licensing costs – but that will save us from throwing away much more money on SQL Server licensing that goes unused.

And I can almost hear the open source folks in the comments saying, “Maybe you should just stop throwing money away on licensing.” Shut up, you.

Previous Post
Why I Love kCura RelativityOne Even Though I Don’t Use It
Next Post
Questions You Should Be Asking About Your Backups

33 Comments. Leave new

  • SQL Server on Linux!!

    Reply
  • I can’t see that this will be an issue as few people now deploy dedicated physical database servers with less than 16 cores. Instead, I’d expect people to deploy a physical host server with 16+ cores but then run a virtual database server on it with just 4 or 8 cores.

    Reply
  • My guess it’s that all this is just to force people move to either virtual environments in house or, if you are not big enough, the cloud…
    It’s a win-win for them, big clients with their own data centers will stay and pay good money in licensing and small customers will run away to the cloud.

    Reply
  • Lorenzo J Huffman
    October 13, 2016 6:34 am

    You can install SQL server and limit it to however many you have licensed or do as the other comments have said and virtualize. Running bare metal is just an unnecessary pain at this point for most applications anyhow.

    Reply
    • Lorenzo J Huffman
      October 13, 2016 6:35 am

      However many cores* you have licensed

      Reply
    • Lorenzo, you might want to check in to that further. Several years back I spec’d out a really beefy server to run SQL 2008 Enterprise, and because of the licensing costs, I specified a single four core CPU. The guy who ordered it saw that it only had one CPU and that a second CPU was only $400, so he ordered a second. I spoke with MS Licensing, and they said that licensing was based on the number of CPUs/cores physically present in the box, disabling access in SQL Server was not good enough. Instantly doubled licensing costs.

      It might be different now as that was 7+ years ago, so check before you commit.

      Reply
      • Wayne – yep, you are correct, and Lorenzo is not. (Lorenzo – time to read the licensing guide that I linked to in the post.)

        Reply
      • Well….perhaps this might look backwardish to you but we (running just two production SQL servers) opted out from visualization and decided to use just physical machines. Troubleshooting performance problems you then have one layer less (the VM) which you should care about. Accidentally our admin ordered a processor bigger than our licensing which also forced us to get another physical processor. Throttling down the Hardware via BIOS was not good enought for MS.

        Reply
  • It’s definitely a bit of a con to force minimum core licencing (more customer frustration will ensue and drive towards Linux) especially triggering a SQL money pit (somewhat sly…) but indeed, thank god (not Microsoft) for virtualisation.

    Reply
  • So looking at the licensing guidelines for Server 2016, it looks like you could keep from blowing your SQL budget while still taking advantage of a 16-core server by virtualizing. Load Server Standard on the host with the Hyper-V Role, then stand up two VMs on the same license (which is allowed) one with the appropriate number of vCPUs for your SQL needs (which you then license SQL for that VM,) the other using whatever cores you have left to handle other workloads.
    Not an optimal solution, but lets you get the most bang for your server buck…

    Reply
    • Exactly. Bare metal = “all cores *must* be SQL licenced”, VM = “only allocated cores to be SQL licenced”. Simples. Use the other cores for more VMs or that 2nd “free Windows Server” VM mega-workload as you note. Not ideal, but avoids SQL cost bombshell, and you can scale up SQL cores afterwards as you need them.

      Reply
    • If you don’t license all the cores of the v-host, there is a minimum of 4 v-cores per virtual machine, another gotcha…

      Reply
  • Virtualized, the minimum licensing is 4 vCPUs (virtual CPU; vCore) per Sql instance. You don’t have to care what’s on the physical box. Unfortunately, that does mean you get less performance out of an Intel chip due to the reality of Hyperthreading and how Hyper-V schedules a vCPU against a “hardware thread”. So a VM setup with 4 vCPUs is effectively running like it’s only using 3 hardware threads—but you paid for 4. E.g. You have 1 pCore, but HT presents that as 2 pCores, and real-world performance is 1.5 pCores due to HT’s architecture (think 2 lines to a single TSA agent at the airport).

    When you consider that a physical install only requires a minimum of four core licenses for each physical processor on the server, you appear to get the best price when you have a single 16-core physical processor and don’t virtualize. If you installed on a VM with the same licenses, you’d only get to use 4 of the hardware threads presented by the 16 pCores (in Hyperthreading, you’d see 32, but effectively have the performance of 24).

    But I hate installing to “bare metal” anymore. {sigh}

    Reply
  • “For years, we’ve been teaching DBAs to buy the bare minimum of cores necessary in order to run their workloads. ” Could you explain it in more detail, please?

    Reply
    • Peter – uh, I’m not sure how I could add more detail to that.

      If you only need 4 cores, build a machine with only 4 cores.

      Don’t build a machine with 64 cores if you only need 4, because you will spend a lot of extra money on licensing.

      What kind of detail are you looking for?

      Reply
      • Yeap, may be I misinterpret it like if I really need 16 cores buying 4 socket 4 cores is better than buying 2 socket 8 cores.

        Reply
        • Buying 4 sockets 4 cores will probably be better performing than 2 socket 8 cores, but only because 4 core processors can have a higher clock speed than 8 core processors (but your mileage my vary). Of course 4 sockets 4 cores will have double the Windows licensing costs (minimum of 8 cores per socket!!).

          Reply
  • The Windows 2016 licensing guide (http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WSSC2016LicensingFAQ.pdf ) at the bottom of page 4 says you can disable physical cores and reduce licensing costs (subject to the minimum 2CPUs and 8 cores per CPU).
    To date, you CANNOT do this for SQL Server – I found this to our cost. I will be endeavouring to get Microsoft to clarify this again. If we could be allowed to disable physical cores to reduce SQL Licensing we can future proof our hardware investment a little, and re-enable cores as business expands by just buying more licensing rather than replacing servers or processors.

    Reply
    • Lorenzo J Huffman
      October 14, 2016 6:42 am

      I can’t find any specifics, but in SQL server management studio there is a config option for how many cores it can use. If that is not acceptable to M$ then I still recomend hyper-v. You can limit the CPU’s for licensing, run 2 vm’s on the box with one standard license, and it makes your entire setup “portable”. I had to restore a print server with one 400 printers just a couple of weeks ago. Restoring from VM backup it worth the few percent performance lost over bare metal.

      Reply
      • Lorenzo – read the licensing guide that’s in the post. (You’d be surprised how useful the contents of the post can be!) While you can configure the number of cores that SQL Server uses, that has nothing to do with licensing.

        For Hyper-V (or VMware or whatever), no, you cannot run two different VMs with one SQL Server Standard Edition license.

        Seriously, stop typing and start reading. You’re costing your employers real money.

        Reply
        • Again, you can license Individual VM rather than the whole physical box.
          So, Lorenzo is correct… If you read SQL 2014 Licensing Guide there’s a section
          call “Licensing Individual VM”.

          Reply
          • No, he said with one license. If you have two VMs, you need two Standard licenses.

          • stand corrected on this case then. cheers

          • Lorenzo seems to be confusing the Windows Server Standard licence (which does allows 2 VMs) with the SQL Standard licence… which would allow a *single* SQL Server on the bare metal / V-Host server OR one of the VMs (but not both VMs – that would be 2 x SQL Servers so 2 licences as Brent says).

  • I’ve probably over thought this to the point of paralysis: I’m buying a single processor, 8-core server that will be running 4 (virtual) servers. The minimum buy is 16 cores for a physical server – got it. But I’m only covered for 2 VMs. Do I have to buy an additional 16 cores, or can I squeeze through with another 8 cores of licensing?

    Reply
    • I’m going to assume that you are talking about Windows 2016 Standard edition licensing (and not SQL Licensing). From the guide:
      Standard Edition provides rights for up to two OSEs or Hyper-V containers
      when all physical cores in the server are licensed. For every two additional
      VMs, all the cores in the server have to be licensed again
      It’s a bit grey – but I’d argue that you only need another 8 cores of licensing. If I were you I’d get a few more VMs on that server and buy DataCentre licensing – licensing model is so much simpler. Also, I do wonder if 2×4 core processors would perform better, as you can get faster clock speeds, and I believe licensing costs would be the same (Windows & SQL). Not sure on the affect of having 2 NUMA nodes instead o 1.
      For SQL licensing – if the 4VMs run SQL Server Standard Edition, you’ll need 16 cores of licensing minimum (more if any of the VMs have > 4 vCPUs). Again, a few more SQL VMs and it would be more cost effective to license with SQL Enterprise Edition (break even point for my hosts are 5 SQL Servers, but I have less cores).
      Hope that’s of some help.

      Reply
      • Pete, thank you! Only one of the VMs will be a SQL server, so licensing there is not an issue. I hadn’t thought of the performance gains having 2x4c processors, great advice! In this instance I can’t define a need for more than 4 VMs, as we are stretching it to run 4.

        Reply
  • Hi all… trying to understand something. I’ve seen several forum posts stating that from Windows 2016 onwards, you can now disable cores in the bios to limit your licensing costs. There have been references to the windows 2016 licensing PDF but i can see nothing in there to indicate you can do this. Any thoughts? I don’t understand why it isn’t good enough to disable the cores in the bios – doesn’t make sense.

    Reply
  • Good point Brent

    Reply
  • I got clarification from Microsoft (via our licensing company), and you’re not allowed to disable cores to reduce licensing exposure for volume licensing. The implication was that for OEM & retail products that MAY be an option – but I didn’t pursue as we use volume licensing.

    Reply

Leave a Reply

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

Fill out this field
Fill out this field
Please enter a valid email address.

Menu
{"cart_token":"","hash":"","cart_data":""}