rust-vmm

rust-vmm is a multi-vendor open-source project providing the shared Rust crates that underpin most modern microVM implementations. Started in 2018 alongside Firecracker, governed jointly by AWS, Intel, Google, Microsoft, Red Hat, Alibaba, and Linaro. The pitch: rather than every VMM rewriting KVM bindings, virtio queues, vhost-user device backends, and memory managers from scratch, share the crates and improve them in one place.

By 2026 the architecture is the foundation under Firecracker, Cloud Hypervisor, libkrun, Dragonball, crosvm, and a long tail of derivatives. A vm-memory improvement lands once and benefits everyone; a fuzzing or formal-verification campaign on virtio-queue covers all downstream VMMs at the same time. See microvm-2026 for the industry context.

What's in the toolbox

The project ships crates across four broad categories:

VM foundation. kvm-ioctls, kvm-bindings, mshv-ioctls (Microsoft's hypervisor on Windows), xen-ioctls, linux-loader — the low-level interfaces to host hypervisors and guest-kernel loading.
Resource management. vm-allocator, vm-memory — guest memory regions, IOMMU support, guest_memfd integration, and (notably) Kani-based formal verification of safety properties.
Device emulation. virtio-queue, virtio-bindings, vhost, vhost-user-backend, vfio-ioctls — the virtio data plane and the protocol for offloading device emulation to a separate process (vhost-user).
vhost-user device backends. can, console, gpio, gpu, i2c, input, rng, scmi, scsi, sound, spi, video, vsock, virtiofsd. Reusable device implementations any VMM can plug in.

Repository layout: historically a constellation of small crates, with a monorepo consolidation announced at FOSDEM 2026 to reduce coordination overhead. RISC-V architecture support landed in the same window.

Why it works

The interesting governance pattern: rust-vmm crates ship as building blocks, not as a complete VMM. AWS still ships Firecracker; Intel still ships Cloud Hypervisor; Red Hat still ships libkrun. Each vendor competes on the integration layer above the shared crates and on the operational story (rootfs images, snapshotting, container integration). The crates themselves are commodity.

This is an unusual outcome — multiple commercial VM products co-developing a substrate library and shipping competing offerings on top of it. It works because the substrate code (KVM bindings, virtio queues) is genuinely common, no one's product story differentiates on it, and the safety/performance benefits of pooled formal verification and fuzzing are large.

The Beganović framing in microvm-2026: "improvements benefit all downstream projects simultaneously. A vm-memory enhancement helps Firecracker, Cloud Hypervisor, libkrun, Dragonball, and crosvm equally."

Why this matters in 2026

The "Docker moment" thesis in microvm-2026 hinges partly on rust-vmm. Most of the AI-agent sandbox platforms surveyed (E2B, Vercel Sandbox, Microsandbox, SlicerVM, Matchlock, etc.) shipped in months, not years. They could because the hard substrate work — KVM bindings, virtio data plane, device emulation, memory safety — was already done. The new vendors built integration, scheduling, and operator UX on top of mature shared crates.

Compare to a hypothetical alternative timeline where every AI-sandbox vendor reimplemented their own VMM from scratch. The category would be 3-5 years behind where it is, and most of the entrants would have shipped subtly broken hypervisors instead of subtly broken UX.

Crate-level safety properties worth knowing

vm-memory has Kani-verified properties for some operations — formal verification, not just fuzzing
guest_memfd integration shrinks the guest-host memory-sharing attack surface compared to traditional virtio bounce buffers
vhost-user separates device-emulation processes from the VMM itself, so a virtio-net bug doesn't grant access to the VMM's memory
IOMMU support in vm-memory means VMMs can give devices DMA access while still constraining them

Repos and links

Org: github.com/rust-vmm
Status (2026): monorepo consolidation in progress; RISC-V support added; multi-vendor maintainership active