Exploring Containers - Part 2: Hyper-V Containers
Containers are a new Microsoft technology coming with Server 2016 that functions like a virtual server, but are faster to deploy. You can read Part 1 of my Containers series here.
In Part 2 of this servers, we’re going to start looking at Hyper-V Containers.
How are ‘Hyper-V Containers’ different from ‘Containers’?
We’ve previously talked about how Virtual Machines are the solution to the problem of hardware resource under-utilization, and how Containers are the solution to the problem of slow VM deployment and complicated VM maintenance. Virtual Machines allow for better resource utilization, but still require pretty much all the same work to deploy and maintain as physical servers. Containers are much faster to deploy than VMs, but they sacrifice some of the process isolation you get with VMs.
Windows Server Containers (or ‘Containers’) allow multiple containers to run on a host with isolation provided though namespace and process isolation.
Hyper-V Containers allow multiple containers to run on a host, however each container is run inside of a utility VM. This provides kernel level isolation between a Hyper-V Container, the Container host, and any other Containers running on the Container host.
The problem that Hyper-V Containers solve is the security concerns of Windows Server Containers. Hyper-V Containers are designed to be deployed within Hyper-V VMs so that administrators can better control the security and process isolation of their Containers, but still have the flexibility to quickly and easily deploy Containers as needed.
Hyper-V Containers are VMs running inside of VMs? You can do that?
Yes.
In order to support Hyper-V Containers, Microsoft is enabling VMs to run inside of VMs in Hyper-V. With Server 2016, you’ll be able to run full Virtual Machines inside of Virtual Machines as well as Hyper-V containers. You’ll be able to go all the way down the rabbit hole, should that be your desire.
Are there different commands to manage Hyper-V Containers?
Nope.
The only difference in management is that to create a Hyper-V Container you need to add a Runtime parameter to the PowerShell command indicating you want a Hyper-V container. Here is what that looks like.
$con = New-Container -Name HYPVCON -ContainerImageName NanoServer -SwitchName "Virtual Switch" -RuntimeType HyperV
This means that while creating applications to run inside of Containers, the programmers do not need to worry about if they will be run inside Windows Server Containers or Hyper-V Containers.
Are there special host deployment considerations for Hyper-V Containers?
As of the current release of Windows Server 2016 (Technical Preview 4), Hyper-V Containers only run on Nano Server. I expect that will change by GA of Server 2016, but you never know.