Microsoft Server Licensing in a Virtual Environment Revisited

Late last year, we published an eBook about licensing Microsoft server operating systems in a virtual environment. This was followed up with a webinar by Thomas Maurer and Andrew Syrewicze. Toward the end of that session, they took some questions. Since then, we’ve received a few more. We’ll use this article to answer those questions and to further expand on some of the ideas in the eBook.

How does OS licensing work with Hyper-V Replica?

The way that licensing works with Hyper-V Replica was covered in the eBook and talked about in the webinar, but is still a very common question topic. Unfortunately, the answer is much less popular. Replicas are actual virtual machines, and they are not the same virtual machines as the ones they are replicating. Therefore, they must be licensed independently of the source virtual machine. The license that you bought for the source virtual machine does not cover the replica.

Of course, that’s just the most basic explanation. As with everything else in licensing, there are always situations that aren’t satisfied so easily. To start, Replicas don’t have to be licensed in the exact same method as the source. The only requirement is that they be legally licensed. This probably won’t mean a lot for most people. Most installations using Hyper-V Replica are probably replicating most, if not all of their virtual machines. However, if you’re somewhere in the middle or if you’re only replicating a few, this might work out in your favor.

Basic Replica Licensing

Replica alternative scenario 1: Many live guests, fewer replicas

Let’s say that you’ve got 20 virtual machines running Windows Server on the source host. You decide to purchase a single Datacenter license to cover them all. But, you only want to replicate two of them. While a Datacenter license for the destination host would certainly cover those two Replicas, it’s overkill. As long as the guests are running Standard edition (and not Datacenter), you can cover both of them by licensing the target host with a single Standard edition license. So, the simple understanding is that Replica licenses are covered on their own terms and are independent of the source VMs.

Licensing Replicas: Many Live VMs with few Replicas

Replica alternative scenario 2: Many source hosts, fewer replica hosts

Preferably, I’d avoid using the term “Replica host”, because there’s really no such thing. Any Hyper-V system can host a Replica and there’s nothing preventing you from mixing Replicas and active virtual machines on the same host. However, we’ll use it here for the sake of convenience.

Let’s say that you’ve built a cluster with five hosts and have a couple of standalone Hyper-V hosts. You’ve designed a disaster recovery site with four unclustered lower-powered hosts. They’ll run all of the same virtual machines, but, due to hardware differences, with a diminished performance profile. For the active five-node cluster, you have to ensure that each node has sufficient licenses to run all the virtual machines they might ever operate at any time. That can be tough to predict. If you’ve designed the disaster recovery site so that its hosts aren’t clustered, then you’ve got a much easier job. Since you have fewer hosts, it’s almost a given that you won’t need as many licenses, even if you’re using the same number of guests.

Many Hosts Replicating to Fewer Hosts

Replica alternative 3: Software assurance

This was mentioned in the original document and in the webinar, but it bears repeating. If the source virtual machine’s virtualization right comes from a license that includes Software Assurance, then you do not need to provide any separate licensing for its Replica.

Replica alternative 4: Desktop and non-Microsoft operating systems

We need to reiterate that this licensing series has focused on the Windows Server operating system as a guest. Desktop versions of Windows in a virtual environment are varied and complicated, but their licensing approaches are always different from those of Windows Server.

As for non-Microsoft operating systems, that’s completely up to whoever owns the product. If it’s a Linux distribution that doesn’t require any purchased license, then you don’t have to pay anyone anything. If it’s any other operating system or other distribution that you’ve have to pay for otherwise, then check with that vendor for their rules. Microsoft does not have any licensing requirement for these operating systems as Replicas any more than they do for them as active virtual machines.

What about Windows desktop operating systems?

The example in the eBook for desktop operating systems talked about a single option, in which each virtual machine required a base full packaged license and at least one other license to make it fully legal in a Virtual Desktop Infrastructure (VDI) environment. For VDI, the computer system used to access the virtual instance must also be properly licensed. This means that you’re going to be paying for a lot of Windows desktop operating system licenses if you want to make VDI a reality.

However, that’s only one option. A relatively recent change in Microsoft licensing is the Virtual Desktop Access license (VDA), which changes the rules in some situations. In others, you might be running a desktop operating system inside a virtual machine but not using it for VDI. Then, there are completely different rules. Of course, you may need to mix and match, depending on your exact needs.

The bottom line is that Windows desktop operating systems do not have a simplistic licensing model in a virtual environment the way that Windows Server operating systems do. While I always recommend that you talk to a credentialed expert in Microsoft licensing about your situation, it’s imperative that you do so when it comes to desktop OSs. There are just too many variables and options to make an easy-to-follow document that will suit every situation.

How do licenses transfers work in a non-cluster failover situation?

We covered clustering pretty thoroughly in the eBook and webinar, but there are other situations in which failure might play a part. For instance, what if you’re running ten virtual machines on a non-clustered system and it fails? Well, non-OEM licenses are transferable, so when you get replacement hardware, just get the virtual machines on it and proceed as you were.

If this is only a temporary situation and you intend to repair the source hardware, you can return the virtual machines back to that hardware without any problem. That’s because the 90-day transfer limitation is waived during instances of hardware failure. Be careful not to abuse this, as the waiver is only intended to return you to a state comparable to pre-failure conditions.

Outside of a failure, each license transfer starts a 90-day clock. Once a license is transferred to a new system, it cannot be legally moved again for 90 days. This is why you must fully license each host in a cluster for the maximum number of virtual machines it might ever run, or you risk being out of compliance.

Does all this apply to Windows Server Foundation and Essentials?

Windows Server Foundation cannot run the Hyper-V role, and although I can’t find anything definitive, it doesn’t appear to be supported as a guest either. I assume it would work, if you wanted to do something like that. Foundation does not appear to be covered by a down-edition from Windows Server Standard or Datacenter, which makes sense when you think about the uses Foundation was intended for.

Windows Server Essentials does support Hyper-V. One license of Essentials allows you to install Essentials on the host and run a single virtual instance of Essentials, provided that you don’t run any other roles in the host. Windows Server Essentials is also not covered by down-edition rights.

How do I work with license keys for guests?

Many questions involved which license keys to use. The first thing to remember is that licenses are licenses and keys are keys. These terms are not interchangeable and they have only a minimal relationship to each other. The licenses are the agreements that you make with Microsoft to legally use their software. The keys are the alphanumeric characters you plug in to keep Windows Server from shutting down.

The key that you type in to any given instance of Windows Server legally doesn’t matter. Any given key might be out of activations or it might be for another edition, but other than that, the Windows Server system will take it. As long as you are legally licensed to run the instance that you place that key into, nothing else really matters. That’s why every single instance out there under Automatic Virtual Machine Activation is using the same key as all the others.

What key you should use in any given situation depends on the operating system version and edition. If it will move to another host through Live Migration or export/import, you don’t need to rekey it. You just need to ensure that the target host has an available virtualization right.

What’s the real story about physical processor counts?

A number of sharp-eyed readers wrote in to let us know about an error in the eBook. In the second example, we said that there were 2 physical CPUs, but the picture showed 4 physical CPUs. That made the rest of the example difficult to understand. To clear that up, the picture was correct but the text wasn’t. We have since corrected the text in the eBook, so feel free to go back to the original page and get an updated copy.

Starting with Windows Server 2012 (previous versions had different rules), Standard and Datacenter editions are both licensed per physical processor pair. Just so this isn’t confused with cores, an easier way to think of this is that licensing is by filled physical processor socket. So, if you start with a dual CPU system and want to run the same number of virtual machines on a quad CPU system, your licensing costs double because you can’t restrict which physical sockets the virtual machines will run on. In the eBook, we compared the dual 8-core system in example 1 to a quad 4-core system in example 2 to show how you would pay double the licensing for the same number of cores. This is the effect of per-CPU pair licensing.

More questions?

As always, I encourage you to take any questions to your license reseller or Microsoft’s licensing team directly. The purpose of these articles and presentations is to introduce you to the basic concepts and get beyond some of the major hurdles. They are not meant to fully explain every possible situation.

When sending in questions, please be aware that we are only talking about Microsoft operating systems in a virtual environment, and are focusing on the server platforms. As we said, the desktop operating system licensing configurations are too varied to cover adequately in the generic sense. Software and server applications are well beyond what we can reasonably cover on a blog dedicated to Hyper-V. For those, seek out the application vendor.

For questions related to Microsoft server operating systems in a virtual environment, we hope that these documents have provided enough information to get you started. As usual, feel free to leave us a comment or send us an email if anything isn’t clear!