Microsoft has dramatically simplified their licensing scheme beginning with Windows Server 2012. Two of the editions, Standard and Datacenter, include guest virtualization rights with each license sold. Standard edition provides for two guests while Datacenter allows an unlimited number of guests. It is important to understand how these work as licensing may influence the number of physical hosts that you purchase.

The terms that Microsoft uses in its licensing documentation to distinguish the operating system that is installed directly on hardware from virtualized guest operating systems are Physical Operating System Environment (OSE) and Virtual OSE, respectively. These terms are rarely used in other contexts. When you purchase Windows Server 2012 Standard or Datacenter licenses, they grant you the right to run one physical OSE on up to two physical processors on the same motherboard. You may then run as many virtual OSEs on those licensed processors as your license allows.

The obvious question in a Hyper-V Server cluster arrangement is: how does this affect migration technologies? The only thing that matters is that the physical processor(s) that a virtual OSE is running on is/are licensed. To make it easy, start by thinking about Essentials edition, which has no virtualization rights whatsoever. If you will run one virtual OSE of Windows Server 2012 Essentials in a cluster of three hosts, that instance can only be migrated to hosts whose processors have been licensed for Essentials. In all likelihood, this means three Essentials licenses.

The reason for this is that all Windows Server licenses are assigned to one or two CPUs and both must be on the same motherboard. If you need another set of CPUs to have that license (perhaps because you need to Live Migrate a virtual OSE to them), then you must re-assign the license to them. This act is considered a transfer. For any given Windows Server license, this can only occur once every 90 days. For some Microsoft products, this 90 day period can be waived within a server farm, but not for Windows Server on your own systems.

The virtualization rights provided by the Standard and Datacenter editions effectively create licensed slots on the CPUs that virtual OSEs can freely move in and out of. The licenses themselves are fixed. There are some things to keep in mind about virtualization rights, and these are given as follows:

Virtualization rights are perhaps best understood through illustration. The following diagrams show some possible scenarios. All assume two-socket hosts; for a four-socket host, simply double the licensing requirements. Our first example, shown as follows, is a three-node cluster with four guests:

That cluster is composed of three hosts with four virtual machines. Each host has been assigned two Standard edition licenses which grant a total of four virtual OSE licenses. One license per host would only allow for two virtual OSEs. In that case, the architect might choose to redesign the hosts such that the cluster only uses two hosts, which would eliminate the need for two of the Standard edition licenses.

As shown, there is nothing wrong with the preceding system. This can be considered a "failover only" configuration in terms of licenses. If hv-node1 crashes, both of the guests will be instantly transferred to hv-node2. Because they both stop running on hv-node1 at the same time before either is started on hv-node2, the cluster remains in compliance. The failed node can be replaced with new hardware without invoking the 90-day clause. However, if the failure isn't permanent, such as a power outage, the 90-day rule applies. Also, if a Live Migration ever occurs, the cluster will not be in compliance. The following image shows this:

This configuration is out of compliance. There are two guest licenses, but they are connected to a single physical processor license which cannot be split across hosts. This cluster can be made compliant through the purchase of a single Windows Server 2012 Standard edition license. Trying to Live Migrate both of the systems at once does not avoid the licensing issue because they will not stop running on the source system at exactly the same time.

The next scenario involves two nodes with only one guest, shown as follows:

This configuration is a little confusing. There is only one physically-bound license but two hosts, both of which are running a copy of Windows Server. However, node hv-node2 isn't running any services, and as this is a cluster configuration, it could be considered an active/passive cluster. In this configuration, some Microsoft server applications only require licensing on the active node. However, this licensing type does not include operating systems, and hv-node2 has a full copy of Windows Server installed. Therefore, it must be fully licensed. Another option would be to build this cluster using Hyper-V Server 2012 as the management operating system instead of Windows Server. That would eliminate the need to buy a second Windows Server license. However, VM1 could only be moved between the nodes once every 90 days. That is because each time it is moved, a license transfer event would need to occur. The recommended solution for this scenario would be to have one Windows Server license for each host. If it doesn't mess up pagination, I would recommend a paragraph break here as we are moving to a new topic. The final example involves Hyper-V Replica and is shown in the following image:

This is a possible disaster recovery design. In this case, the build assumes that if cluster cl-hv1 fails entirely, VMs on cl-hv-replica can be brought up in its place and the two Datacenter licenses will transfer. Unfortunately, this is not a valid assumption. Virtual machines serving as Hyper-V Replica targets must be licensed as though they were actively running virtual machines. The recommended solution in this case will be to purchase enough licenses to cover all four hosts.

Even though licensing is much less complicated in Windows Server 2012 than it was in previous Windows Server versions, and R2 has retained that simplicity, it can still be very confusing. Microsoft only makes major changes to their licensing scheme in conjunction with major new product releases, but their master Product Use Rights document is updated quarterly. You can review it at the following location: http://www.microsoft.com/licensing/about-licensing/product-licensing.aspx.

A simpler document with examples is available at http://www.microsoft.com/licensing/about-licensing/briefs/virtual-licensing.aspx.

The licensing discussion as presented in this book should be used as nothing more than a basic guideline to help you conceptualize licensing needs. You are always strongly encouraged to work with Microsoft or a licensing reseller to determine your exact needs. If you would like help from a Microsoft licensing expert, they provide telephone-based assistance (http://support.microsoft.com/kb/141850). Any authorized Microsoft license reseller should have a licensing expert available for consultation, and many will often provide licensing consultation at no charge.

Two other types of software need to be considered. The first is software that will run on management operating systems. As a rule, you shouldn't install anything within a management operating system that isn't absolutely required to be there. This will generally include things such as management tools and backup software agents. These types of applications will typically be licensed per node. Software that provides other services, especially to computers besides virtual OSEs, can cause violations of the licensing agreements for your physical OSEs. If your license is for Windows Server 2012 Standard edition and all virtualization guest rights are consumed, it is a violation of the licensing agreement to provide any services to other computers or users. There is no concern if the software is solely for the purpose of managing, monitoring, or providing services to the management operating system or its virtual machines.

The second type is software that will run on the guest machines. Hopefully, these will all be licensed to the virtual machine and there will be no issues. However, there are a few vendors that bind their software to physical hardware. Ensure you check with each vendor for software you intend to place in a cluster to ensure that you remain in licensing compliance.