Novm challenges the definition of what’s a container and what’s a VM

Just when you thought all the possibilities had been exhausted for hypervisors, containers, and VMs, along comes another contender to stir fresh ingredients into the pot.

Novm — produced under the auspices of Google, although not an official Google product according to its GitHub description — is a type 2 hypervisor ( akin to VMware Workstation, rather than VMware ESX) written in Go, leveraging Linux’s KVM, and focused on running applications rather than whole systems.

Intriguingly, it “exposes a filesystem device as a primary mechanism for running guests,” according to the project page. Instead of defining a disk image to be used with the VM, the user notes what directories are to be made visible to Novm — and the list can be changed in real time, allowing directories to be added or removed on the fly while the system is running.

Novm’s creators — chiefly Adin Scannell, a systems software developer at Google — point out several advantages over containers for their system, aside from making it less problematic to manage disk instances. Unlike a container-based system, Novm can run any kernel on the host that it knows how to boot, so guest and host can run entirely different versions of Linux with different mixes of modules. Also, this model has better security than containers, since the only interfaces exposed are that of the x86 ABI and the hypervisor itself. (“Containers are more likely to suffer from security holes as the guest can access the entire kernel system call interface,” the creators explain.)

In a LinuxCon presentation delivered last August, Scannell (also the creator of the Huptime utility) described some of what he perceived as the limitations of containers. They’re heavily dependent on the host’s kernel, making security more difficult than it might seem, and they create problems with shared kernel state, which is “complex and difficult to isolate,” as “migration, suspend, and resume are much harder.” Rather than try to make containers more like VMs, his idea with Novm was to try and make a VM more like a container that sported Docker-style deployment, could map in directories from other file systems with no more than a command, and could address some of these problems.

The current disadvantages to Novm’s approach are threefold: speed (I/O-intensive workloads come with many caveats), support for a very small number of hardware devices, and support only for Linux kernels at this time. The second restriction limits Novm to running modern-stack applications. As Scannell put it, “You can’t migrate your untouchable, ancient IT system over to Novm.”

One analogy for the explosion in products that explore the spectrum of possibilities between hypervisors, VMs, and containers is the way smartphones underwent a similar explosion in form factors, from the conventional handset up to the “phablet” that proved a surprising success. Each form factor satisfied varying needs for different customers, even if the needs weren’t visible to other customers — or to other smartphone makers.

In the same way, experiments like these that explore relocating the dividing line between a VM and a container are meant to scratch itches that IT folks might not know they had. Clearly Docker was able to satisfy one major itch, but it’s entirely possible projects like Novm may find and satisfy other needs that haven’t been vocalized.