Building a VMM from Scratch: Why BoxLite is Replacing libkrun

Introduction: The Birth of a New VMM Project

The Virtual Machine Monitor (VMM) is the core component of modern lightweight virtualization technology. A technical blog post that's been gaining traction in the developer community — "Building a VMM from scratch, #0: Why BoxLite is replacing libkrun" — serves as the opening entry in a "Building a VMM from Scratch" series, explaining why the new project BoxLite aims to replace the existing libkrun solution.

It's worth noting that this article is based on publicly available information about the project. Since the primary source material consists mainly of the title and community discussion threads, the following content focuses on the technical background surrounding VMMs, libkrun, and lightweight virtualization — helping readers understand the value of projects like this.

What Are VMMs and libkrun?

VMM: The Foundation of Lightweight Virtualization

A VMM is responsible for scheduling and isolating resources between the host and guest operating systems. Unlike traditional heavyweight virtual machines (such as the full QEMU/KVM stack), the micro VMMs (microVMs) that have emerged in recent years place far greater emphasis on fast boot times, low memory footprint, and a minimal attack surface. AWS's Firecracker and Google's crosvm are prime examples of this philosophy.

VMM implementations rely on hardware virtualization extensions. Intel VT-x introduced the VMX (Virtual Machine Extensions) instruction set, splitting CPU execution modes into root mode (host) and non-root mode (guest). This allows the guest to execute most instructions directly without VMM intervention — only triggering a VM-exit event (such as I/O operations or privileged instructions) when the VMM needs to step in. AMD's equivalent technology is AMD-V (SVM). This hardware mechanism is precisely what allows microVMs to deliver near-native performance with minimal overhead. The KVM (Kernel-based Virtual Machine) module in the Linux kernel exposes these hardware extensions as the /dev/kvm device file; user-space VMMs (like Firecracker, crosvm, and libkrun) interact with KVM via ioctl calls, enabling virtual machine creation and management without writing kernel drivers.

What Is libkrun?

libkrun is a project that wraps VMM capabilities into a shared library, allowing developers to embed it directly into their applications to run isolated workloads with minimal overhead. It's commonly used for container security isolation and sandboxed execution — tools like Podman benefit from similar approaches for certain security features. libkrun's core value proposition is "virtualization as a library," making isolation as easy to integrate as calling an ordinary function.

Architecturally, libkrun is written in Rust, reuses portions of device emulation code from crosvm under the hood, and uses the virtio protocol to enable efficient I/O communication between host and guest. virtio is a paravirtualization device specification: the guest OS must have the appropriate virtio drivers installed, in exchange for significantly higher network and disk throughput compared to fully emulated devices. libkrun's embedded-library design means the calling process itself acts as the VMM host — a contrast to the traditional approach of launching QEMU as a separate child process — further reducing inter-process communication overhead. However, this tight coupling also means that upstream API changes or architectural decisions in libkrun directly affect any application embedding it. This is one of the practical reasons some teams choose to build their own replacement.

Why BoxLite is Replacing libkrun

From the title "Building a VMM from scratch," it's clear the BoxLite author has chosen to build from the ground up rather than continue building on libkrun. This kind of technical decision typically stems from several considerations:

• Control: Building your own VMM means complete ownership of the codebase — enabling on-demand feature trimming, performance optimization, and freedom from upstream dependencies.
• Lightweight design: As the name "BoxLite" suggests, achieving a smaller footprint and lower runtime overhead is likely a core objective.
• Maintainability and learning value: The process of building from scratch is itself a deep dive into the underlying mechanics of virtualization. The serialized blog format (starting at #0) signals the author's intent to treat this as a long-term project balancing both teaching and practical engineering.

In the lightweight virtualization space, "replacing an existing solution" is rarely a verdict on the old solution's quality. More often, the new project wants to make different trade-offs in specific dimensions — such as boot latency, memory footprint, or API design — that are a better fit for its own needs.

The Technical Significance of Building a VMM from Scratch

Value to the Developer Community

A public, serialized project that walks through VMM construction from zero is an exceptionally valuable reference for developers who want to understand the fundamentals of virtualization. Virtualization touches on many complex areas: CPU virtualization extensions (Intel VT-x, AMD-V), memory management, device emulation (virtio), interrupt handling, and more. Comprehensive, step-by-step tutorials on these topics are rare.

The Trend Toward Lightweight VMMs

The rise of microVMs reflects a balancing act in the cloud-native era between two competing demands: security isolation and boot performance. Serverless functions, hardened container runtimes, and edge computing are all driving a continuous push for lighter, faster, and more secure VMM solutions. BoxLite is a natural continuation of this trend.

Key metrics for evaluating microVM performance typically include: cold start time (from the creation API call to the guest kernel being ready), memory overhead (host memory consumed by the VMM itself), and the size of the TCB (Trusted Computing Base). Firecracker's official benchmarks show cold start times as low as 125 milliseconds, with roughly 5 MB of memory overhead per VM. A smaller TCB means a reduced attack surface — in contrast to a full QEMU stack with millions of lines of code, microVMs typically implement only a handful of virtio devices (net, block, vsock) and deliberately omit complex features like USB and PCI hotplug, trading breadth for security auditability. This design philosophy directly shapes the feature boundary decisions made by new projects like BoxLite.

Conclusion

BoxLite's decision to replace libkrun reflects a developer's pursuit of full ownership and extreme lightness in the lightweight virtualization space. For readers interested in systems programming and virtualization technology, following this "Building a VMM from Scratch" series will be an excellent window into the implementation details of modern microVMs. If this topic interests you, we recommend reading the original posts and following future updates in the series for the complete technical picture.