Microsoft Licensing in Containers

by Alexander Golev

It took Microsoft a few years to get to grips with containers and finally come up with definitive licensing terms and conditions for "containerised" environments.

The "virtual container" technology emerged a few years ago but there were no specific licensing rules for containers. And by the way, the question of how to license previous versions of Microsoft software in containers still remains a grey area.

But there's a confusion even with the current versions of Microsoft software. Because Windows Server and SQL Server treat containers differently.

What's a container? For dummies, please

Feel free to skip this chapter if you already know it. Others, buckle up, and let's quickly dive in to the fantastic world of virtualisation.

In the very beginning, computers were just… well, "simple" computers.

Before computers came with Windows and MacOs pre-installed, we used to buy "barebones", "empty" computers. And the first thing we did was to install an operating system.

An operating system is something that every computer has – Windows, MacOS, Linux, on top of which runs software, your day-to-day applications.

It used to be that simple: one computer – one operating system, whether the computer was a workstation or a server. Until at some point, someone had a clever idea – why don't we "fool" a program and create a virtual environment for it, which will look to that software as if it was a hardware computer.

To achieve that you would run a special program called "hypervisor" inside the core operating system, and it would create "virtual computers", which will themselves run operating systems of their own, and software in those.

And so there goes my lousy explanation of what virtualisation is. It's just creating virtual computers inside a physical one. Why? There are lots of benefits and reasons, but this is not what this article is about.

So, in the "traditional" (LOL) virtualised world you run one physical operating system, inside which you run a number of virtual operating systems, or as Microsoft calls them, “OSEs” – Operating System Environments, which is a more precise term, in my opinion.

But with that comes a problem. Because each time you need to virtualise something, you need to create and deploy a new operating system. You need to maintain it. Each operating system needs resources. Each operating system needs maintenance. These are all additional overheads. And sometimes you just don't need that level of isolation.

So, other clever people came up with the following idea: why don't we somehow isolate software inside the core operating system without deploying new, virtualised operating systems? Let's create a sandbox, a bubble, that will share the main operating system of the computer, but certain settings and certain things will be isolated and specific to that software. Again, let's not concentrate on benefits of doing so (except that it creates less overheads).

That may be a bit complicated to understand if you're not an IT person. So, for a normal human being, it's just, well, another way, clever way to run computer software.

So, to summarise: a virtual machine creates a new operating system environment that looks like a complete computer; and containers, on the other hand, do not create operating systems. They run inside the core operating system of the computer.

And then I wish, it was that simple

Unfortunately, it doesn't end there. Microsoft created a new way to run containers, which they call “containers with Hyper-V isolation”.

What such container essentially is, it's called "a container", but technically, it's a virtual machine.

You don't create and deploy a virtual machine for it yourself. You don't configure it yourself. It is done for you. It runs in a cut-down version of the Microsoft Windows Server operating system. But it's still a virtual machine.

You sort of run the software as a container, but it's not run inside the core operating system. A new virtual machine is automatically created for it.

And these “Hyper-V isolated” containers are the source of confusion around Microsoft licensing in containers. And I remind you: there's a difference between Windows Server and SQL Server.

How that affects Windows Server licensing

When you run a "traditional" container using, for example, Docker, you do not create a new virtual machine, a new operating system environment. But when you run a container with “Hyper-V isolation”, an operating system environment is seamlessly created for you in the background.

Therefore, containers with “Hyper-V isolation” consume Windows Server licenses just like "traditional" Windows Server virtual machines would do.

For myself, not to be confused, I just remember that a container with “Hyper-V isolation” is a separate virtual machine. So, it's counted as a virtual machine. And all the virtual machine licensing rules for Windows Server apply to that cut-down version of a virtual machine.

But please, please, please, please, do not confuse that with

SQL Server licensing in containers

Because it is different, and the rules are simpler.

For the purposes of SQL Server licensing, each container equals an operating system environment.

An OSE not created when you run a "traditional" container (without Hyper-V isolation). Its's just how Microsoft stipulated the terms. For the purposes of SQL Server licensing, any container equals an operating system environment.

Therefore, when you count licenses for SQL Server, treat each container as a virtual machine.

And that affects “Unlimited Licensing”; that affects the limit on the operating system environments when you don't have Software Assurance on SQL Server Enterprise licenses; that affects the counting of unlimited instances inside of an operating system environment, and all the other aspects of SQL Server licensing.

TL/DR; Let's summarise

Windows Server:

• A container without “Hyper-V isolation” does not consume a license;
• A container with “Hyper-V isolation” consumes a license.

SQL Server:

• Each container regardless of Hyper-V isolation counts as a virtual machine.

I know, it's still complicated. Microsoft licensing is not easy despite what you may have heard. But I sincerely hope that I’ve taken away at least a bit of that confusion.

If you'd like to learn more about Microsoft licensing and make fewer mistakes and save on Microsoft licensing, follow us on LinkedIn and subscribe to our channel.

And if you would like us to take away your Microsoft Licensing headaches, please let us at SAMexpert know using this simple form, and we'll respond to you ASAP.