Cloud Hypervisor
A ~106K-line Rust microVM Virtual Machine Monitor that keeps Firecracker's minimal spirit but adds the features general-purpose cloud workloads need — nested KVM, GPU passthrough, hotplug, Windows guests. Intel-originated (2019), built on rust-vmm, and the VMM Dedalus forked into DHV. Source: emirb.github.io/blog/microvm-2026, 2026-06-21; Dedalus Machines - How They Work
What it is
Cloud Hypervisor is a KVM-based microVM monitor, started by Intel in 2019 and now stewarded across Intel and Microsoft. It shares its low-level code (KVM bindings, virtio device models, memory management) with Firecracker through the Rust VMM crate ecosystem; the core is heavily built on the same crates. ~106,000 lines of Rust as measured with cloc in March 2026. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Scalpel vs Swiss Army knife
The defining contrast is with Firecracker. Firecracker is a scalpel — it removes features to minimize attack surface (no GPU passthrough, no CPU hotplug, no nested virtualization), tuned for AWS Lambda's threat model of short-lived functions. Cloud Hypervisor is the Swiss Army knife Source: emirb.github.io/blog/microvm-2026, 2026-06-21:
- Nested KVM (
--cpus nested=on, added December 2025) — run a hypervisor inside the guest. - VFIO device passthrough — including GPUs.
- CPU / memory hotplug — resize a running VM.
- Windows guest support.
The cost is a few dozen ms slower boot and a slightly larger attack surface. In synthetic benchmarks the virtualization overhead for both VMMs is in the low single-digit percentages. Deciding question: if workloads need Docker-in-Docker, Android emulators, /dev/kvm inside the VM, Windows, or any complex setup → Cloud Hypervisor; if only ephemeral compute → Firecracker. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Who uses it
Fly.io runs Firecracker for standard workloads but brought in Cloud Hypervisor for GPU Machines that need PCIe passthrough (burning months on Nvidia host drivers, at one point hex-editing closed-source drivers to make them think CH was QEMU). Northflank offers it as one of four selectable isolation backends. KubeVirt opened a Hypervisor Abstraction Layer (v1.8, March 2026) to support CH beyond QEMU/libvirt. Ubicloud runs each VM under Cloud Hypervisor inside Linux namespaces for additional isolation. Source: emirb.github.io/blog/microvm-2026, 2026-06-21
Relevance to Kevin: DHV
Dedalus's VMM, DHV (Dedalus Hypervisor), is a fork of Cloud Hypervisor — chosen over Firecracker precisely because Dedalus Machines need the heavier feature set (live migration, vCPU/memory hotplug via ACPI GED + virtio-mem, virtio-fs over vhost-user for S3-backed persistent home directories). One DHV process runs per workspace. The positioning line "we forked Cloud Hypervisor and made it better, so wake is sub-second" comes straight from this choice. Source: Dedalus Machines - How They Work; Dedalus Machines - Positioning & Pitch
See Dedalus Machines - How They Work for the full DHV/host-agent/storage-daemon stack, MicroVM and Sandbox Isolation Architecture for the isolation architecture, and Containers Are Not a Security Boundary for why the VM boundary matters.
Timeline
- 2026-06-21 | Page created from emirb's microVM-isolation survey and Kyle Jeong's Firecracker explainer, cross-referenced with Dedalus's internal architecture doc. Captured the scalpel-vs-Swiss-Army-knife contrast with Firecracker, the nested-KVM/VFIO/hotplug/Windows feature set, the production user list (Fly GPU, Northflank, KubeVirt, Ubicloud), and the DHV fork that powers Dedalus Machines. Source: emirb.github.io/blog/microvm-2026, 2026-06-21; Source: X/@kylejeong, 2026-05-11