SYSTEM Cited by 1 source
Intel Cloud Hypervisor¶
Cloud Hypervisor is an open-source Rust-written KVM-based Virtual Machine Monitor (VMM) incubated by Intel, architected as a Firecracker sibling — same micro-VM posture (small attack surface, fast boot, minimal device model), written in Rust, KVM-only — but with PCI device passthrough support that Firecracker does not surface. Upstream: https://github.com/cloud-hypervisor/cloud-hypervisor.
Seen in (wiki)¶
- Fly.io GPU Machines run on Cloud Hypervisor, not Firecracker. Fly.io's first wiki disclosure of the hypervisor-per-workload- class split: non-GPU Fly Machines run on Firecracker; GPU Fly Machines run on Cloud Hypervisor so that an Nvidia GPU can be attached to the guest via PCI passthrough. Fly.io describes the two as "a very similar Rust codebase" — the choice is driven by the PCI- passthrough requirement, not by a fundamental difference in hypervisor posture. (Source: sources/2025-02-14-flyio-we-were-wrong-about-gpus)
Why Fly.io chose it¶
The alternative hypervisors on Nvidia's driver happy path were VMware (institutionally rejected) and QEMU. "We like QEMU fine, and could have talked ourselves into a security story for it, but the whole point of Fly Machines is that they take milliseconds to start. We could not have offered our desired Developer Experience on the Nvidia happy-path." (concepts/fast-vm-boot-dx).
Cloud Hypervisor preserved the Firecracker-class fast-boot DX Fly.io requires and added PCI passthrough, at the cost of pushing Fly off Nvidia's supported driver path — Fly.io "burned months trying (and ultimately failing) to get Nvidia's host drivers working to map virtualized GPUs into Intel Cloud Hypervisor. At one point, we hex-edited the closed-source drivers to trick them into thinking our hypervisor was QEMU." (Source: sources/2025-02-14-flyio-we-were-wrong-about-gpus)
Architectural posture¶
- KVM-based. Like Firecracker, delegates hardware virtualisation to Linux KVM.
- Rust. Memory-safe VMM code path.
- Micro-VM shape. Minimal emulated-device surface; fast boot; small memory footprint per VM.
- PCI passthrough + IOMMU — the key feature that distinguishes it from Firecracker for hardware-accelerator workloads (GPU, FPGA, NIC).
- vhost-user + virtio for paravirtualised IO.
- Snapshot / restore / live migration support.
- Workload fit — public-cloud-style workloads plus hardware-accelerated workloads (GPU, custom silicon) where PCI passthrough is the only integration path.
Why it matters¶
- First-class micro-VM alternative to Firecracker for the non-AWS-Lambda-shaped multi-tenant-VM use case. Firecracker is tightly coupled to Lambda's design assumptions; Cloud Hypervisor makes different trade-offs (more device support, including PCI passthrough).
- GPU virtualisation in micro-VMs is still Nvidia-off-path. Fly.io's negative datum is the wiki's cleanest disclosure: even Cloud Hypervisor's PCI-passthrough + IOMMU surface wasn't enough to get Nvidia's virtualized-GPU drivers working. Fly.io pivoted to whole-GPU passthrough — which does work, but blocks MIG / vGPU thin-slicing.
Related¶
- systems/firecracker — the sibling Rust VMM without PCI passthrough; Fly.io uses Firecracker for non-GPU Machines.
- systems/fly-machines — GPU variant runs on Cloud Hypervisor; non-GPU variant on Firecracker.
- systems/qemu — the conventional-hypervisor alternative on Nvidia's happy path; rejected by Fly on boot-latency grounds.
- systems/nvidia-l40s / systems/nvidia-a100 — the GPU SKUs Fly passes through to Cloud-Hypervisor guests.
- systems/nvidia-mig — the thin-sliced-GPU path that remained inaccessible even on Cloud Hypervisor.
- concepts/gpu-as-hostile-peripheral — the security framing that motivated the micro-VM-with-PCI-passthrough posture.
- concepts/nvidia-driver-happy-path — the Nvidia-driver integration surface that Cloud Hypervisor sits outside.
- concepts/fast-vm-boot-dx — the Fly DX requirement Cloud Hypervisor preserved.
- companies/flyio — canonical user in the wiki.