Microsoft’s Hyper-V was introduced with Windows Server 2008 as a platform for hosting virtual machines. Since its humble beginnings, Hyper-V has evolved in ways that nobody could have predicted back then. One of Hyper-V’s biggest architectural changes came about when Microsoft gave Hyper-V the ability to act as a container host.
Virtual machines vs. containers
Although Hyper-V has the ability to host both containers and virtual machines, the two could not be more different. Virtual machines are just that – a virtualized representation of a physical computer. Like a physical machine, a virtual machine has its own operating system.
Additionally, a virtual machine is fully isolated from other virtual machines that may be running on the host. If a problem (such as a Blue Screen of Death error) happens within a virtual machine, that issue will not typically impact neighboring virtual machines since each VM acts independently.
Containers are another type of virtualized environment but work in a very different way from virtual machines. Whereas a virtual machine is a virtualized representation of a physical computer, containers virtualize individual applications — not the entire machine.
Containers running on a host generally share a common base image. The base image contains the operating system that the containerized applications depend on. The containers themselves store application binaries and related dependencies such as registry entries or DLL files that are required in order to run the application. Because containers do not include an operating system, they tend to be much smaller in size than virtual machines (often measuring mere megabytes in size) and are also easily portable. A containerized application can easily be moved from a lab environment to a production environment, or from an on-premises environment to the cloud.
Why the lines between virtual machines and containers are blurring
The point that I wanted to make in the previous section is that containers and virtual machines couldn’t be more different from one another. Even though Hyper-V can host both virtual machines and containers, there are major architectural differences between the two, and containers serve an entirely different purpose from virtual machines.
But what if it were possible to use Hyper-V’s container architecture to benefit virtual machines? That is exactly what Microsoft has done with at least one utility. Microsoft has been able to leverage the Hyper-V container architecture to bring new features and capabilities to Hyper-V virtual machines. If you haven’t seen these new features, it’s probably because they are not exposed through the Hyper-V Manager, nor are they exposed through Windows PowerShell.
One of the new capabilities enabled by the underlying container infrastructure is the ability to organize Hyper-V virtual machines into CPU groups. CPU groups are essentially collections of Hyper-V VMs that have similar CPU requirements or that need to be collectively throttled in order to cap CPU utilization. A comprehensive discussion of CPU groups is beyond the scope of this article, but the important takeaway is that even though the CPU Groups feature is meant to be used with Hyper-V virtual machines, it is wholly dependent on the container architecture. Let me explain.
Introduction to the Host Compute Service
Microsoft’s decision to support containers in Windows Server came with some major architectural challenges. One such challenge was the fact that Docker containers had already been around for quite a while and were widely being used. As such, Microsoft had to build its container ecosystem to work with what was already in place. This meant supporting the existing Docker commands and components.
A second challenge that Microsoft faced was the fact that Docker containers were designed to be used in open-source environments. Docker had been built for Linux and was never intended to run on Windows Server. As such, Microsoft had to come up with a way of making Docker containers natively run on the Windows Server operating system, but without altering the container architecture in the process (otherwise, containers might cease to be portable).
Microsoft’s solution to these and other challenges was to develop an API that the company calls the Host Compute Service, or HCS. The Host Compute Service is what allows the Docker Engine and Docker components such as libvontainerd, libnetwork, graph, and plugins to work with the Windows operating system.
While it is possible to make direct calls to the Host Compute Service, Microsoft has created a couple of wrappers that make the API easier to use. One of these wrappers is the dotnet-computevirtualization wrapper, which you can download from GitHub. You can use this wrapper to create containers, and future versions will also allow for the creation of virtual machines.
A second wrapper called hcssim is also available from GitHub. This wrapper is written in Go and enables the Golang interface that is used when launching Docker containers.
So, what about those new virtual machine features and capabilities that I talked about earlier? As previously mentioned, Microsoft has made it so that you can create CPU groups for virtual machines, but this capability is not exposed through the Hyper-V Manager or through PowerShell. To the best of my knowledge, it is not exposed through System Center Virtual Machine Manager, either.
Rather than exposing CPU groups through any of the conventional management interfaces, Microsoft has constructed a standalone command-line tool called CpuGroups.exe. Because CPU grouping can only be accomplished by way of the Host Compute Service, this command-line tool presumably makes calls directly to the HCS API.
A new Systems Center?
For right now, there isn’t a lot of information available about Hyper-V VM utilities that are based on the HCS API. It’s entirely possible that CpuGroups.exe is the first such tool. Over time though, I expect this to change. I expect that in time Microsoft will eventually build a new System Center tool that acts as a single pane of glass mash-up of Virtual Machine Manager and Kubernetes. Such a tool would allow for side-by-side management of both virtual machines and containers. Because that type of tool would have no choice but to make HCS API calls, it would probably be easy for Microsoft to enable additional VM capabilities through similar API calls.
Featured image: Shutterstock
