chris - Fotolia


Differences between Windows Server Containers, Hyper-V Containers and VMs

Isolation levels between Windows Server Containers and Hyper-V Containers differ. Although Hyper-V Containers leverage Hyper-V VMs, there are major differences between the two.

Of all the new features introduced in Windows Server 2016, perhaps none has received as much attention as containers....

Although containers have been prevalent in the open source world for quite some time, they are new to Windows. In many ways, Windows Containers are similar to Linux containers. Both, for example, can be managed using Docker. However, there are some aspects that are unique to Windows. For instance, Windows Server 2016 supports the use of Windows Server Containers and Hyper-V Containers. This raises the questions of how these container types differ and how Hyper-V Containers differ from Hyper-V VMs.

Windows Server Containers vs. Hyper-V Containers

Functionally, Windows Server Containers and Hyper-V Containers are very similar. They both do the same thing, and are managed in basically the same way. The primary difference between the two is in the level of isolation they provide.

Unlike VMs, which each have their own OS, containers share a common OS kernel. Each container is an isolated user mode environment that sits on top of a shared OS. This means that containers are far smaller than VMs, since containers don't include an OS.

The problem with containers sharing an OS is that applications can have varying needs, and a single OS image might not be appropriate for all containers. Furthermore, even though containers are designed to be isolated from one another, multi-tenant environments generally try to avoid sharing an OS kernel across tenant boundaries.

This is where Hyper-V Containers come into play. Hyper-V Containers work in exactly the same way as Windows Server Containers, except that Hyper-V Containers and their dependencies are encapsulated inside Hyper-V VMs. Hence, it's possible for Hyper-V Containers to have their own base OS image or multiple Hyper-V Containers can share a common base OS image.

Hyper-V Containers vs. Hyper-V VMs

Although a container can be made to run an application, such as SQL, containers are best suited to running microservices or stateless applications, such as web servers.

Although Hyper-V Containers technically make use of Hyper-V VMs, there are some very significant differences between Hyper-V Containers and Hyper-V VMs. These differences are tied to the general use case for a container.

As you are no doubt aware, VMs are virtualized representations of physical machines. A VM is equipped with virtualized hardware, an OS, drivers, an application and anything else you might need to make the VM's workload functional. Containers are far different. For one thing, containers are much smaller than VMs. As previously noted, containers don't even contain an OS.

Although a container can be made to run an application, such as SQL, containers are best suited to running microservices or stateless applications, such as web servers. The reason for this is that, believe it or not, containers are essentially designed to be disposable. The presumption is that because containers are so light weight, they can be dynamically deployed on an as needed basis, and then removed just as easily when they are no longer needed.

So, if containers can be deleted on a whim, what happens to the data within the container? As you probably know, Hyper-V VMs are usually equipped with one or more virtual hard disks. A virtual hard disk is a VHD or a VHDX file that the VM uses in place of a physical hard disk. One of the key differences between a container and a VM is that containers don't have virtual hard disks.

A container is really nothing more than an isolated space in which an application is allowed to run. Because everything in a container needs to be kept isolated from other containers and from the underlying infrastructure, the container is designed to redirect any write operations to a sandboxed area within the container itself. The sandbox contents are automatically deleted whenever the container stops. This is why containers usually run microservices or stateless applications. Containers just aren't designed for data persistence. Sure, it's possible for a container to make use of an external data source, but the container itself doesn't store persistent data.

Although Hyper-V Containers rely on Hyper-V VMs, there are significant differences between containers and VMs. It's also worth noting that although Hyper-V Containers are encapsulated inside Hyper-V VMs, you don't have to manage these VMs in the same way you might manage a normal VM. The OS performs any required Hyper-V-level management tasks, such as creating or optimizing the VM, automatically.

Next Steps

Deploy Windows Containers in Microsoft Azure

Use Windows Containers for disaster recovery

Decide between Windows Containers and Hyper-V Containers

Dig Deeper on Microsoft Hyper-V management