Rust VMM
A shared ecosystem of Rust crates — KVM bindings, memory management, virtio device models — that any VMM project can build on. It's the reason a handful of competing companies all ship good microVM monitors: they reuse the same battle-tested foundation instead of reinventing it. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
What it is
After AWS open-sourced Firecracker (a Cloud Hypervisor sibling effort followed), every new VMM kept reinventing the same low-level components: KVM wrappers, virtio device models, memory management. AWS, Intel, Google, Microsoft, Red Hat, Alibaba, Linaro, and others recognized the waste and started collaborating on rust-vmm, a shared set of Rust crates. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
The crate ecosystem as of 2026 (per the FOSDEM 2026 talk by Stefano Garzarella, Ruoqing He, and Patrick Roy):
- Core VM:
kvm-ioctls,kvm-bindings,mshv-ioctls(Hyper-V),xen-ioctls(Xen),linux-loader - Resource management:
vm-allocator,vm-memory(IOMMU support,guest_memfd, Kani formal verification) - Device emulation & I/O:
virtio-queue,virtio-bindings,vhost,vhost-user-backend,vfio-ioctls,vm-superio - vhost-user devices: can, console, gpio, gpu, i2c, input, rng, scmi, scsi, sound, spi, video, vsock,
virtiofsd
Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Why it's "the real revolution"
The survey's central claim is that rust-vmm — not any single VMM — is the breakthrough. It means the industry doesn't have one good VMM; it has a shared foundation that makes many good VMMs possible, each optimized for different trade-offs. An improvement to vm-memory benefits Firecracker, Cloud Hypervisor, libkrun, Dragonball, and crosvm at once. A new architecture (RISC-V) implemented once in the crates is inherited by every consumer. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Consumers span the industry: Firecracker (AWS), Cloud Hypervisor (Intel/Microsoft), crosvm (Google/ChromeOS), libkrun (Red Hat), Dragonball Sandbox (Alibaba/Kata), OpenVMM (Microsoft), and virtiofsd (the reference virtio-fs daemon). This breadth is why building a new sandbox platform takes weeks, not years — the hard problems are already solved in the crates. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Current direction (2026)
Announced at FOSDEM 2026: consolidation into a monorepo (the kvm, vfio, vm-virtio, and vhost workspaces are already merged) plus RISC-V architecture support and POSIX/*BSD portability. Formal verification via Kani proofs is being applied to memory-management crates. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Relevance to Kevin
The shared substrate beneath Dedalus's VMM (DHV, a Cloud Hypervisor fork). Improvements to rust-vmm crates flow into the Dedalus stack for free, and the convergence on KVM + shared crates is part of why the agent-infra sandbox market commoditized so fast — the moat is what you wrap around the VM, not the VM itself. See Containers Are Not a Security Boundary and MicroVM and Sandbox Isolation Architecture.
Timeline
- 2026-06-21 | Page created from emirb's "Your Container Is Not a Sandbox" survey (citing FOSDEM 2026). Captured the crate inventory, the cross-company consumer list, the monorepo + RISC-V + Kani direction, and the "shared foundation, not a single VMM" thesis. Source: emirb.github.io/blog/microvm-2026, 2026-06-21