Unikernels: Rise of the Virtual Library Operating System

What kind of paper is this?

• Hybrid: Desribes a system, but is also a nice overview of library operating systems/unikernels.
• I love how the paper summarizes the story (kind of) in a single line at the beginning: "What if all the software layers in a virtual appliance were compiled within the same safe, high-level language framework?"
• Loved this line too, "Are we really doomed to adding new layers of indirection and abstraction every few years, leaving future generations of programmers to become virtual archaeologists as they dig through hundreds of layers of software emulation to debug even the simplest applications?"
• Ooh, ooh, ooh, "Precise dependency tracking from source code (both local and global libraries) and configuration files lets the full provenance of the deployed kernel binaries be recorded in immutable data stores, sufficient to precisely recompile it on demand."

The Story

• Once upon a time, people bought computers to run their applications. Then, some large companies decided to sell time on their enormous clusters of machines. Virtualization and virtual machines allowed these large providers to multiplex one physical machine among many customers. However, virtualization just adds one more layer to an already deep software stack. The folks from Cambridge suggest compiling individual applications together with library operating systems and their machines to create something called a unikernel. Unikernels were lightweight and fast, and everyone lived happily ever after.

VMs to unikernels

• VMs address the problem of having to continually add support for new devices to every operating system. Instead, the hypervisor deals with real drivers, and VMs can simply write to virtualized drivers.
• LibOS can also leverge this, but requires that we use hypervisor to spawn a VM for each application -- how is that VM different from a process? (I suppose you can have different OS implementations.)

Four big idea in MirageOS

1. Static type checking
2. Automatic memory management
3. Modules
4. Metaprogramming (unifies configuration and coding)

Building an application

• Track dependencies from application through OS (How is this difference from CDE? End to end type checking.)
• Uses a SAT solver in the OCaml dependency manager, which uses the solver to find dependencies (still not entirely clear on this).
• Compile the application with all the kernel modules.

Diversion: Why OCaml

• Functional, imperative, and OO all wrapped together.
• Static type checking
• Portable single-threaded runtime
• Fast native code
• Strong module system allows safe code reuse and refactoring
• Used OCaml module system to decompose the kernel

Feature Analysis

1. Features that are common practice
   • Design for cloud deployment.
2. Features that are not used and should stay that way
   • OCaml as system implementation language (Maybe I'm wrong here, but I do have some concerns.)
3. Features that are not used but should be reconsidered
   • LibOS: I find this idea pretty attractive, although I wonder if it pushes more resource management into the hypervisor than it's really up for.
4. Features for which the jury is out
   • Using a SAT solver for dependency tracking.