SQL Server 2016 Virtualization Licensing Guide
Licensing SQL Server 2016 for virtualization
SQL Server 2016 offers customers a unique level of flexibility when licensing in virtual environments – with options to license for maximum/unlimited virtualization or to carve out just the computing power needed by licensing individual virtual machines (VMs). In this document, we will cover each of these options and the related licensing rules in detail. First, let’s start with a brief overview of these two paths.
SQL Server 2016 Virtualization – Licensing individual virtual machines
Microsoft offers the unique option to license VMs individually. This is in contrast to other database vendors in the industry that usually require customers to license the entire server, even when the workload utilizes only a fraction of the available computing power. The option to license individual VMs is designed to help organizations use hardware resources more cost-effectively by carving out and paying for just the computing power that is needed. SQL Server can be licensed in individual VMs using the “Per Core” or the “Server+CAL” licensing model.
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.
Server+CAL licensing model: SQL Server 2016 Standard Edition customers purchase one server license for each VM running SQL Server software. In this model, each user or device accessing SQL Server 2016 must also be licensed with a SQL Server 2016 Client Access License (CAL).
Note that individual VMs may also be licensed for SQL Server 2016 Enterprise Edition through the Server+CAL model. See page 7 for more details.
SQL Server 2016 Virtualization– Licensing for maximum virtualization
As virtualized environments grow and become more dynamic, customers have the option to license for maximum virtualization, which can dramatically simplify software licensing management.
■ SQL Server 2016 Enterprise Edition customers who have licensed all of the physical cores on the server, and have Software Assurance (SA) coverage for those licenses, may deploy any number of VMs on that server.
■ SQL Server 2016 Enterprise Edition customers who have licensed all the physical cores on the server, but who do not have SA coverage, can only deploy a number of VMs equal to the number of core licenses assigned to the server.
Next, we will discuss these licensing rules in more detail and walk through a few use cases to help illustrate how these can be applied in real-world scenarios.
SQL Server 2016 Virtualization – Scenario 1 Server consolidation
Licensing individual VMs
Server consolidation has been a major driver of virtualization in today’s IT environments. Virtualizing workloads and consolidating them onto fewer physical servers can improve hardware utilization and reduce server hosting and administration costs.
As an example, consider a manufacturing company that has a reporting workload running on a SQL Server 2016 database, hosted on a dedicated server. Similarly, the company has CRM and HR applications built on SQL Server databases, and each running on their own dedicated server. After purchasing new high capacity hardware, the company decides to virtualize these three workloads and move them to a single server.
In this scenario, the company chooses to license each VM individually. This provides the flexibility to license only the computing power required by each SQL Server workload. Let’s look in depth at how to license individual VMs in this example using each of the available licensing models.
Licensing individual VMs in the Per Core model
To license each of these VMs in the Per Core licensing model, this customer must purchase a core license for each virtual core allocated to the VM. Consistent with Per Core licensing in the physical environment, there is a four core minimum license requirement for each VM. (Note that for licensing purposes, a virtual core is equivalent to a virtual thread and may also be referred to as a virtual processor or virtual CPU.)
To illustrate this, we’ll continue with our manufacturing company example in which three workloads have been virtualized and consolidated on a single server. In this example, these workloads are static and will remain on the server.
The company needs to determine its virtual licensing requirements based on the number of virtual cores in each VM. As you can see in the graphic above:
■ The first VM with one virtual core requires four core licenses to meet the four core minimum requirement.
■ The second VM requires four core licenses, one for each virtual core.
■ The third VM requires six core licenses.
As a result, the company purchases a total of 14 core licenses, which are sold in packs of 2-core licenses.
SQL Server 2016 Virtualization – Hyper-threading
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.
- 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. A core license allows a single virtual core to be supported by a single hardware thread.
- Conversely, if a single hardware thread is supporting multiple virtual cores, a core license is still required for each virtual core.
It should be noted that a customer could license all the physical cores in the server with Enterprise Edition and Software Assurance to gain use rights for unlimited virtualization. This option may be more cost effective and provide greater deployment flexibility. (We will cover this topic in more detail later in the document.)
■ For customers with versions prior to SQL Server 2016, please refer to the appendix of this document for information on licensing options and rules.
Licensing individual VMs in the Server+CAL model
Many customers license SQL Server using the Server plus Client Access License (Server+CAL) licensing model, which is based on the users or devices accessing the software. As introduced earlier, these customers can license for virtualization by purchasing one server license for each VM that is running SQL Server software. When licensing VMs, customers can assign multiple server licenses to a single physical server (one for each VM running on that server).
Continuing with our manufacturing company example, let’s assume that in this case the instances of SQL Server in the physical environment had been licensed under the Server+CAL licensing model. Now, three server licenses will be required for the virtual environment – one for each virtual machine (three Standard Edition server licenses). This is true regardless of the number of virtual processors allocated to the VM. In addition, each user or device accessing SQL Server 2016 software requires a SQL Server 2016 CAL. Note: SQL Server CALs allow access to multiple VMs.
SQL Server 2016 Enterprise Edition Server+CAL customers
Even though the Server+CAL licensing model is no longer available for Enterprise Edition (effective with the release of SQL Server 2012), many customers are able to upgrade their existing software to SQL Server 2016 through Software Assurance. Customers who have deployed SQL Server 2016 Enterprise Edition software in the Server+CAL model are eligible to license up to four VMs for each Enterprise Edition server license. These customers can assign multiple Enterprise Edition server licenses to a single server to deploy additional VMs.
It’s important to note that each Enterprise Edition server license is limited to a total of 20 hardware threads of power across the (four or fewer) VMs for which it is licensed. Multiple licenses can be used to add more VMs, but not to increase the amount of compute power used by a single operating system environment (OSE).
See the table below for the number of VMs allowed per server license for each SQL Server 2016 edition.
Licensing individual VMs is a great option for organizations that want the flexibility to carve out and license the needed computing power from their hardware. However, as virtual environments become more dynamic and utilize more servers, this may also create a complex set of licensing requirements that must be monitored to ensure compliancy. Next we will discuss how to license SQL Server in more dynamic virtual environments where licensing requirements change frequently to meet shifting business needs.
SQL Server 2016 Virtualization – Scenario 2 Dynamic virtual environments
Many organizations have virtual computing environments that are dynamic – meaning that the virtual environments are spread across multiple virtual servers, and VMs are moved across these servers occasionally to reallocate resources. In some cases, VMs are moved dynamically by the hypervisor. These dynamic scenarios can make software licensing more complicated, depending on how customers choose to license their virtual workloads. To help simplify licensing for these scenarios and to provide greater flexibility, Microsoft offers License Mobility within server farms, which allows licenses to move between servers along with the VMs.
License Mobility
License Mobility is a benefit available for any edition of SQL Server 2016 software licensed with Software Assurance coverage. License Mobility offers a great advantage to customers who license individual VMs and then need to reassign those licenses to different servers to accommodate moving workloads.
To help understand how License Mobility can be put into practice, consider our manufacturing company example. As the company grows, it adds more physical servers and begins to multiply its workloads across additional VMs. To maximize server utilization, the company periodically “moves” its VMs to different physical servers in its datacenter.
With License Mobility, this company is able to reassign licenses to different servers within the server farm as often as is needed. So any time one of these VMs moves to a different server, the license moves with it. This can provide significant cost savings as well as simplicity in licensing. Without License Mobility, the company could only move licenses to a different server once every 90 days, which for this example means the company would need to maintain enough licenses on each server to cover the peak number of VMs that could be moved to the server at any time.
Another scenario in which License Mobility can help save costs is when organizations host virtualized workloads both in their datacenters and in the public cloud. As these “hybrid” IT infrastructures grow and become more dynamic, customers can move a workload to a VM role in the cloud and seamlessly move the license with it. License Mobility provides the flexibility to help address this need.
There are a few additional considerations to be aware of with License Mobility:
- As mentioned earlier, customers with SQL Server Enterprise Edition Server+CAL licenses can license up to four VMs per server. If customers intend to use this licensing model in a dynamic environment, it’s important to note that to gain the benefits of License Mobility, the VMs licensed with a single Enterprise Edition server license must move together to the same server at the same time. This may not always be possible, in which case customers must assign one Enterprise Edition server license to each VM being deployed.
- A server farm may consist of up to two data centers located in time zones that are within four hours of one another and/or with the European Union (EU) and/or European Free Trade Association (EFTA).
- While License Mobility allows dynamic movement of VMs within a server farm at any time, SQL Server licenses can only move to VMs hosted by third party providers once every 90 days.
■ For more detailed information on License Mobility, refer to the “SQL Server 2016 Licensing Guide”, which can be found here: http://go.microsoft.com/fwlink/?LinkId=230678
Today, many virtual environments are becoming even more dynamic, especially in scenarios where software is used to automatically and dynamically allocate resources to different VMs “on the fly”. In the next section, we will discuss licensing SQL Server in these scenarios and look at ways to further simplify licensing management.
SQL Server 2016 Virtualization – Scenario 3 High volume dynamic virtual environments
Licensing for maximum virtualization
For organizations with a large number of VMs and complex, highly dynamic virtual environments, Microsoft offers the option to license for maximum virtualization. This means that when all of the cores on a server are licensed with SQL Server Enterprise core licenses and covered with Software Assurance, a customer can deploy any number of VMs on the server.
The key benefits of licensing for maximum virtualization are simplicity and potential cost savings. Maximum virtualization ensures that customers are covered, without needing to be concerned with tracking individual VMs or the amount of power assigned to each VM. 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.
As an example of how maximum virtualization can be employed, let’s look at the creation of a private cloud infrastructure, where hundreds of databases are consolidated into a single virtual environment.
In this scenario, an organization has deployed high performance hardware, where the physical servers are combined as a pooled virtual resource that supports a large number of VMs. Further complicating this scenario for licensing purposes is that the VMs are being moved dynamically between the server blades in the appliance to maintain peak performance.
By licensing all of the physical cores in the appliance with SQL Server Enterprise core licenses, and covering those licenses with Software Assurance, the organization can deploy an unlimited number of VMs. This can dramatically simplify licensing, as the organization can be assured that all VMs are correctly licensed, even when they are dynamically moved across the different servers in the appliance. The customer can also spin up as many new VMs as they need without ever needing to buy additional licenses.
One important factor when licensing for maximum virtualization is to determine which use rights apply. When deploying VMs on a server, the use rights of the most recent licensed version apply to every VM on the server. For instance, if a customer is using SQL Server 2008 R2 processor licenses (with Software Assurance), to license for maximum virtualization and upgrades any of the VMs to SQL Server 2016, SQL Server 2016 use rights would now apply for every VM running on that server.
In scenarios like this one, it may still be possible to license VMs individually but it is likely to be difficult to manage. There are a few caveats to consider when licensing individual VMs in highly dynamic environments.
■ SQL Server 2016 Enterprise Edition Server+CAL customers As mentioned earlier, in dynamic environments like this, customers would need to assign an Enterprise Edition server license to each VM to ensure that they are properly licensed at all times. While customers can license up to four VMs with a single Enterprise Edition server license, as VMs are moved dynamically in this scenario, it would be impossible to ensure that all four VMs move together across the servers. In this case, License Mobility will not work and it is strongly recommended that one Enterprise Edition server license is assigned to a single VM.
■ Dynamically changing power usage in VMs In some scenarios, the power allocated to each VM is scaled up and down dynamically to meet the changing needs of the workload and to maximize server utilization. In this case, it may be impossible to track virtual core-based usage if customers license individual VMs with core licenses.
SQL Server virtualization rights for prior software releases
The following overview summarizes the software virtualization rights for current and prior versions, editions and licensing models of SQL Server software. This summary should not be a substitute for careful review and understanding of your rights and obligations as described in your Microsoft Volume Licensing agreement and the Product Terms. When reviewing virtualization rights for prior versions, it’s important to keep these things in mind:
- Product use rights for the originally licensed version and edition apply even if using downgrade or cross-edition deployment rights. For example, if a customer purchases a SQL Server 2016 license, SQL Server 2016 use rights apply even if the customer deploys SQL Server 2012 (or an earlier version).
- If customers (who are eligible through SA) have upgraded from a previous version, the product use rights for the running software version apply. For example, if a customer upgrades from SQL Server 2008 to SQL Server 2016, SQL Server 2016 use rights apply.
- License Mobility moved to an SA benefit with the release of SQL Server 2012. So any license covered with SA, regardless of which version or edition of the software is deployed, will have License Mobility rights.
Additional notes when licensing individual VMs:
Under the Server+CAL licensing model, SQL Server CALs are required for any user or device accessing SQL Server functionality or data, regardless of whether SQL Server or any of its components are running a physical or virtual OSE.
When licensing individual VMs under the Per Core licensing model, all virtual cores supporting the VM must be licensed, with a minimum of four core licenses required. No additional CALs are required. For licensing purposes, a virtual core maps to a core (when hyper-threading is turned off) or a hardware thread (when hyper-threading is on).
When licensing individual VMs under the legacy Per Processor licensing model, all virtual processors (v-cores) supporting the VM must be licensed. No additional CALs are required. For licensing purposes, a virtual processor maps to a core (when hyper-threading is turned off) or hardware thread (when hyper-threading is on). To calculate the number of processor licenses required for each VM, divide the number of virtual processors in the VM by the number of physical cores (or threads) per physical processor. If this results in a fraction, round up to the next whole number.
Download the document:
(© Microsoft Corporation. All rights reserved. The information in this document represents the current view of Microsoft on the content.)