Man contemplating costs of licensing SQL Server per VM or per VM host

Virtualization Model: Financial Trade-offs for Virtual OS Environments

Should you license SQL Server per VM or per VM host?

In one of my previous posts, "Enterprise or Standard? A Hands-On Planning Tool to Get it Just Right," I shared a planning tool for analyzing the financial trade-offs between using Enterprise Edition vs. Standard Edition. This week I wanted to share a variation of the tool for virtualization. Specifically, this version would enable you to consider the financial trade-offs of using different licensing options for Microsoft SQL Server running on a virtual machine (VM), which Microsoft calls a Virtual OS Environment (OSE).

The tool is designed to help you answer a question I frequently get: "Should I license SQL Server per VM or per VM host?" As we've discussed previously, with 63% of SQL Server running virtualized in private datacenters, this is very common.

Real-World Scenario

Here's the scenario: You have a number of SQL Server instances and the choice is to license each VM using SQL Server 2014 Standard Edition (SE) or license all the cores of the physical VM hosts using SQL Server 2014 Enterprise Edition (EE). Some of the key factors to consider in the analysis are:

  1. Microsoft VM 4 core license minimum
  2. What is the ratio of VMs per physical host?
  3. Size of the physical hosts in terms of CPUs and cores

A snapshot of the model's output is given below:

SQL Server TCO Tool virtualize output

The first input is your number of SQL Server instances to virtualize. Let's assume there are currently 50 instances to virtualize and you will deploy 1 instance per VM. 

Next, we input the virtualization level, the number of VMs per physical host. In this case, we set the virtualization level to 8 because we want to make sure that each VM is allocated 2 physical CPU cores. As we'll show later, all things being equal, this number has a huge impact on the analysis. Then, we enter the number of CPUs per host, the number of cores per CPU, and the number of years of support. In our example, those are 2, 8, and 3 respectively.

The first set of outputs breaks out the number of EE core licenses required for the hosts and the number of SE core licenses required for the VMs. Note that even though we only plan to allocate 2 cores per VM we have to buy 2 extra SE core licenses per VM because of Microsoft's 4-core licensing minimum. 

Next, you input your SQL Server 2014 license, Software Assurance (SA) and VMware vCloud costs. For the purposes of the exercise, I used the latest list prices I had access to (which are subject to change). We added SA to the analysis because it removes the licensing reassignment frequency restriction of only once every 90 days, which really doesn't make any sense for a live virtualized production environment. And as they say, the model does the rest. It calculates the total costs for each different case.

Choice Becomes Clear

In this case the choice is pretty clear . . . license each VM using 2014 SE. Even with Microsoft's ridiculous 4-core license minimum per VM and using SA, you would save almost 50% over licensing the VM hosts with EE. But, as we said before a well-crafted model should make it easy to explore different scenarios. For us that would be how could we make using EE a more viable option. I gave a hint earlier as to what we might do to impact the analysis. That would be to change our virtualization level—it's currently set at 8 VM's per physical host. If we change the virtualization level to 13, this reduces the number of physical hosts required from 7 to 4 and EE is only 12% more expensive then SE. We'll have to be more careful with our capacity planning because not every VM can be allocated 2 physical cores, but with processor hyper threading this scenario definitely becomes a more viable option. 

I hope the analysis sparked some new ideas. Remember, the goal is to stay in compliance and minimize your SQL Server costs: "Not too hot or not too cold . . . just right."

As before, if you would like a copy of the tool just send me an email at [email protected].

Until next time . . . .

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.