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

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

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

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!

 

Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

11 thoughts on "Microsoft Server Licensing in a Virtual Environment Revisited"

  • Jorge Luis says:

    Hi:
    my scenario:
    primary Hyper-V Host, with a 2CPU Datacenter Licence and 10 VM, the replicar server shas another 2 CPU Datacenter Licence. What rights do I have with this setup? I need to buy more licences ¿?

    • Eric Siron says:

      If each one of these hosts has 2 physical CPUs and its own Datacenter license, you can run all the live and replica VMs of Windows Server on them that you want.

  • Jorge Luis says:

    Hi:
    my scenario:
    primary Hyper-V Host, with a 2CPU Datacenter Licence and 10 VM, the replicar server shas another 2 CPU Datacenter Licence. What rights do I have with this setup? I need to buy more licences ¿?

  • Juri says:

    I just had a very difficult talk with my software provider for SPLA licensing. We have a primary host (single, no cluster) with a Windows 2012R2 Datacenter license. This one host runs all active VMs.
    Then we have a secondary host, dedicated to backup the VMs on the primary host, but also runs some active VMs, covered by windows standard licenses. For selected VMs we also use replication from primary to secondary host.
    Both hosts use their local storage, there is no shared storage.

    Here comes the real deal: We NEVER run the replicas on the secondary host. We only store the replicated content of the associated VHDX files. In order to test the replicas from time to time, we run them on the primary host, where we have the datacenter license.

    So in fact, in our case the replica feature is only used for backup, VMs are never loaded into RAM. If we would need to failover, then of course loading the VMs into RAM on the secondary host would mean that we would need to pay the monthly license in our case as SPLA providers.

    Microsoft states clearly, that storage is out of their licensing scope, no matter what kind of licensing you’re on.

    Our software provider had a hard time to figure the right answer to this but finally came up with one. They say that we don’t need licenses for the secondary host for these replicated VMs, as long as they are never loaded into RAM.

    How is your view on this?

    Thanks
    Juri

    • Eric Siron says:

      I have to take the “out” here that SPLA licensing might be different in this regard because I haven’t looked very closely at what, if anything, makes it different from volume/retail. However, for both volume and retail, the mere existence of the Replica requires it to be licensed. This is because it is not a backup, no matter how you use it. It is a virtual machine that is in a standby mode, somewhere between powered off and powered on. It’s not a “backup” because Replicas aren’t restored, they’re just turned on.
      This situation is mentioned specifically in the Product Use Rights document as being a privilege granted by Software Assurance. In other cases, you need a full license to cover the Replicas. My instincts tell me that your software provider is wrong and that you should seek a second opinion. In this regard, I would probably seek guidance from Microsoft’s licensing team directly.

  • Juri says:

    I just had a very difficult talk with my software provider for SPLA licensing. We have a primary host (single, no cluster) with a Windows 2012R2 Datacenter license. This one host runs all active VMs.
    Then we have a secondary host, dedicated to backup the VMs on the primary host, but also runs some active VMs, covered by windows standard licenses. For selected VMs we also use replication from primary to secondary host.
    Both hosts use their local storage, there is no shared storage.

    Here comes the real deal: We NEVER run the replicas on the secondary host. We only store the replicated content of the associated VHDX files. In order to test the replicas from time to time, we run them on the primary host, where we have the datacenter license.

    So in fact, in our case the replica feature is only used for backup, VMs are never loaded into RAM. If we would need to failover, then of course loading the VMs into RAM on the secondary host would mean that we would need to pay the monthly license in our case as SPLA providers.

    Microsoft states clearly, that storage is out of their licensing scope, no matter what kind of licensing you’re on.

    Our software provider had a hard time to figure the right answer to this but finally came up with one. They say that we don’t need licenses for the secondary host for these replicated VMs, as long as they are never loaded into RAM.

    How is your view on this?

    Thanks
    Juri

  • Martin Osbourne says:

    Hi
    We Sent a link to your artical to our Microsoft Contact and he replied below

    From this we are under the impression that the replica server holding the replicated VM’s is NOT required to be licensed so long as the stated conditions are met

    January 2015 PUR (pg. 69 of 81)

    Servers — Disaster Recovery Rights

    • Other than backup instances run on Microsoft Azure Services, Windows Server license is not required for the disaster recovery server if the following conditions are met:
    • The Hyper-V role within Windows Server is used to replicate virtual OSEs from the production server at a primary site to a disaster recovery server.
    • The disaster recovery server may be used only to
    • run hardware virtualization software, such as Hyper-V,
    • provide hardware virtualization services,
    • run software agents to manage the hardware virtualization software,
    • serve as a destination for replication,
    • receive replicated virtual OSEs, test failover, and
    • await failover of the virtual OSEs.
    • run disaster recovery workloads as described above
    • The disaster recovery server may not be used as a production server.

    What are your thoughts ?

    Thanks Martin

    • Eric Siron says:

      Looks like a new conditional set that gets you out of licensing if you have a replica site used purely for failover.

  • Martin Osbourne says:

    Hi
    We Sent a link to your artical to our Microsoft Contact and he replied below

    From this we are under the impression that the replica server holding the replicated VM’s is NOT required to be licensed so long as the stated conditions are met

    January 2015 PUR (pg. 69 of 81)

    Servers — Disaster Recovery Rights

    • Other than backup instances run on Microsoft Azure Services, Windows Server license is not required for the disaster recovery server if the following conditions are met:
    • The Hyper-V role within Windows Server is used to replicate virtual OSEs from the production server at a primary site to a disaster recovery server.
    • The disaster recovery server may be used only to
    • run hardware virtualization software, such as Hyper-V,
    • provide hardware virtualization services,
    • run software agents to manage the hardware virtualization software,
    • serve as a destination for replication,
    • receive replicated virtual OSEs, test failover, and
    • await failover of the virtual OSEs.
    • run disaster recovery workloads as described above
    • The disaster recovery server may not be used as a production server.

    What are your thoughts ?

    Thanks Martin

Leave a comment or ask a question

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

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.