In the last two years there’s been an explosion of interest in the potential of application containers. Some look to containers as the infrastructure grease to help expedite deployment, integration, testing and provisioning – package once, run anywhere. Others point to the resource management capabilities typically associated with VMs and the low overheads of container instantiation. Many have mused on the relationship between containers and virtual machine (VMs) – are they competitive or complementary?
Last year at VMworld, we stressed the latter – that containers and VMs work better together. At that time, we were already two months into our work on Project Bonneville, hoping to deliver on that message in a very literal sense. Our goal was to provision containers directly to virtual infrastructure as first-class citizens and to do it efficiently, quickly and transparently.
When we initially proposed a 1:1 model between containers and VMs, it was met with widespread skepticism. Doesn’t this construct negate the majority of the benefits of a container? Why should containers be a special case – isn’t the hypervisor intentionally workload-agnostic? One year later, our half-pizza team here at VMware is proud to have reached the point where we can share a technology preview with the world and blog publically about our progress.
The design principles of Bonneville take a pure approach to the notion of containers on the hypervisor. In the abstract, a container is a binary executable, packaged with dependencies and intended for execution in a private namespace with optional resource constraints. A container host is a pool of compute resource with the necessary storage and network infrastructure to manage a number of containers. Around this, you have an ecosystem that provides dependency-management, image resolution, cloud storage, etc. Companies such as Microsoft and CoreOS are successfully challenging the assumption that a container must necessarily be a Linux construct.
If we accept these descriptions of containers and container hosts, then arguably a VM fits the abstract description of a container perfectly, and a hypervisor or some part thereof is an equally suitable container host. There’s compelling advantages to hardware virtualization in this brave, new, containerized world, and with Bonneville, we can deliver them with minimal additional cost.
Bonneville is a Docker daemon with custom VMware graph, execution and network drivers that delivers a fully-compatible API to vanilla Docker clients. The pure approach Bonneville takes is that the container is a VM, and the VM is a container. There is no distinction, no encapsulation, and no in-guest virtualization. All of the necessary container infrastructure is outside of the VM in the container host. The container is an x86 hardware virtualized VM – nothing more, nothing less.
We recently tested the flexibility of this abstraction by taking a legacy operating system – one never designed for use with containers – and integrating it with Docker. We chose MS-DOS 6.22 partly for nostalgia, and partly because it neatly encapsulates a simple legacy OS. In 48 hours, we were able to use a vanilla Docker client to pull a Lemmings image from a Docker repository and run it natively in a 32MB VM via a Docker run command. The image was built using a Dockerfile, layered on top of FAT16 scratch and DOS 6.22 OS images with TTY and graphics exported back to the client. Given another 48 hours, I’m confident we’d have had volume support and networking integrated.
That’s a win for the flexibility of hardware virtualization, but what about efficiency? vSphere’s “Instant Clone” technology (aka Project Fargo) already facilitates fast and efficient VM provisioning; with Instant Clone, we’re able to provision child VMs directly from a parent ROM image in memory where they start out with a theoretical footprint of zero. Every byte written to memory is a copy-on-write diff from the parent, so the footprint of the child VM is only ever its mutable memory. The more advanced the initialization of the parent, the faster and more efficient the children. Bonneville is only beginning to tap the potential of Instant Clone; further efficiencies are gained by bootstrapping the parent with a custom “Pico” version of VMware Photon, weighing in at around 25MB.
A Bonneville container host can theoretically run containers of any kernel version of any operating system and can do it fast and efficiently. What other benefits are there of this hardware-virtualized approach? Here are a few points to consider:
- Security and isolation. If you try to break out of a Bonneville VM, the only thing you’re likely to find is the BIOS.
- Freedom from Linux distribution management. Not sure what Linux distro to use as a container host? Worried about maintenance, patching, upgrades, sizing, multi-tenancy or kernel version? With Bonneville, there are no such worries. Your containers live in virtual spaces that are dynamic, secure and already have well-trodden upgrade paths. If you really want a Linux container host, Bonneville can provision a Linux container host as a container.
- Portability. Provided you stick with Linux, any container created in Bonneville can be committed and run on any vanilla Docker host.
In summary, Bonneville is the container ecosystem you love, on the hypervisor you trust. We look forward to bringing you further updates in due course.
- A quick overview of Project Bonneville
- A demonstration of Project Bonneville
- More on VMware Cloud-Native Apps
About the Author: Ben Corrie (@bensdoings) is the Principal Investigator on Project Bonneville, a native container solution for VMware’s hypervisor.