First look: Run VMs in VMs with Hyper-V containers
Windows Server 2016’s Hyper-V containers are lighter weight than traditional VMs and more secure than traditional containers
By Simon Bisson
Contributor, InfoWorld |
Due for release in the second half of 2016, Windows Server 2016 is a major reworking of the Windows Server platform, with a refactored core that will scale from the minimalist, microservice- and cloud-focused Nano Server to the familiar graphical user experience. Windows Server 2016 is perhaps best thought of as Microsoft delivering its Azure cloud platform to on-premises installations. The latest preview, Windows Server 2016 TP4 (Technical Preview 4), adds a range of new Azure-like features, including enhancing the container features introduced in Windows Server 2016 TP3.
Jeffrey Snover, lead architect for the Windows Server division, describes the process thusly: “Taking public cloud patterns and practices and making them available everywhere.” That would certainly explain what Microsoft is delivering with its container solutions in Windows Server 2016. Containers have become a key element in modern build processes, allowing developers and operations teams to deliver consistent encapsulated services that operate in isolated user land, along with supporting elements, where what’s developed is what is delivered and what is operated.
The debut of Docker-based containers in TP3 offered a glimpse at how Microsoft is approaching server-based application isolation. TP4 fills in many of the gaps in Windows Server 2016’s container support, though it still maintains the separation between PowerShell- and Docker-managed containers. It also adds support for the promised Hyper-V containers, which use a minimal virtual machine host to increase process isolation by running containers inside the Hyper-V hypervisor.
Marrying VMs and containers
It’s important to understand the differences between Hyper-V virtual machines and Hyper-V containers. Hyper-V virtual machines remain the foundation of a private cloud infrastructure as a service, while Hyper-V containers introduce a new virtualization option. Hyper-V containers achieve a greater degree of isolation than Docker or Windows Server containers through the use of hardware virtualization. Think of them as highly isolated containers or lightweight virtual machines. You can’t manage a Hyper-V container from the Hyper-V management tooling in Windows Server 2016. Instead you’ll use the PowerShell and Docker tooling introduced in the previous technical preview.
Getting started with containers in Windows Server 2016 TP4 is a lot easier than in the previous release. A single PowerShell cmdlet enables container support in all versions of the server, from the full graphical shell to Nano Server. With Microsoft suggesting that Windows Server 2016 virtual infrastructures should be based on its UI-less Server Core options, it’s not surprising that much of the container management tooling is based on PowerShell, as PowerShell offers both local and remote management options. With SSL support due in a future technical preview, PowerShell will also support encrypted management connections.
Similarly, it’s easier to build the Nano Server images you’ll need to try out Hyper-V containers and Nano Server-hosted virtualization. You can build a Nano Server virtual hard drive from the TP4 install media using a set of bundled PowerShell scripts. These let you build an image quickly, then inject the appropriate features to support both containers and Hyper-V. Other cmdlets set up nested virtualization and configure the appropriate number of processors for a host virtual machine. Still others let you download container images from Microsoft that you can use as baselines for your applications and services.
You’ll need to set up a NAT virtual switch for the containers to use. That too is handled by a PowerShell cmdlet, making it possible to automate the process of rolling out containers on new servers, and to use Remote PowerShell to work across a large network of servers and VMs. One note: If you’re hosting containers on a VM, you’ll need to enable MAC address spoofing.
Existing Nano Server-based Windows Server containers can be converted to Hyper-V containers, using the Set-Container cmdlet to change the container runtime. Set –RuntimeType to HyperV and restart your container to take advantage of improved isolation. Once running, each Hyper-V container has a related Virtual Machine Worker Process. You can find which process is associated with which container relatively quickly, as the process user is the container ID.
The Goldilocks option
That’s probably the most important aspect of Hyper-V containers: They’re simply another deployment option. You can switch from one container type to the other depending on how you’re hosting your containers, or how well you trust that image you’ve downloaded from Docker Hub. Because the switch between modes is another command-line option, it’s easy to automate and to incorporate into any build and test process. Everything leading up to a Hyper-V container or Windows Server container deployment is exactly the same. You can wait to decide on one environment or the other right up until the last minute.
If you’re planning on hosting Hyper-V containers on a virtual infrastructure, you’re going to need to enable Nested Virtualization. This is another new Windows Server 2016 feature, added in the latest builds. It allows a Hyper-V virtual machine to host its own virtual machines. In addition to making it easier to build complex virtual infrastructures for test and development, Nested Virtualization gives you the ability to run isolated microservices in Hyper-V containers alongside traditionally virtualized servers and services. But be sure you have plenty of memory: Microsoft currently recommends 4GB per nested host.
Because Hyper-V containers isolate the container kernel from the underlying operating system, they are not only more secure than Windows Server containers, but also more portable. For developers, that means being able to take a Hyper-V container running on-premises and move it to Azure or any other cloud provider running Windows Server 2016, knowing it will run the way you expect. For system managers, it means that isolated code is truly isolated, so it's much less risky to run self-service container deployments or to host multitenant services in a high-density environment.
Hyper-V containers aren’t for everyone. If you trust your code, then you’re going to stick with traditional containers where the trade-off between isolation and resources allows you to deliver highly dense microservices. If you don’t trust the code you’re running, in dev/test scenarios, or in hosting, or with third-party services you haven’t fully verified, then Hyper-V containers are an ideal compromise. You get deep isolation, while still being able to host apps using the familiar PowerShell or Docker commands.
We’re still several months from the release of Windows Server 2016, but the big picture is starting to take shape. It is becoming increasingly clear that Microsoft is committed to its hybrid cloud model, where workloads can move seamlessly from private to public clouds, and where Hyper-V containers are bound to play a large role.
Related articles
Copyright © 2015 IDG Communications, Inc.