← Back to research
·11 min read·opensource

Cloud Hypervisor

Cloud Hypervisor is a Linux Foundation-governed, Rust-based virtual machine monitor (KVM and Microsoft Hypervisor) that boots to userspace in under 100ms and adds what Firecracker won't — PCI/GPU passthrough, device hotplug, and live migration. It is the VMM under Azure AKS Pod Sandboxing.

https://www.cloudhypervisor.org ↗
container-vm-runtimesopen-sourcerust

Key takeaways

  • Foundation-governed and vendor-diverse — a Linux Foundation project with contributors and supporters spanning Intel, Microsoft, ARM, AMD, Alibaba, ByteDance, Ampere, SAP, and Tencent Cloud
  • The fuller-featured rust-vmm sibling of Firecracker: same minimal-emulation philosophy and sub-100ms boots, but with PCI/GPU passthrough (VFIO), CPU, memory, and PCI hotplug, live migration, and Windows guest support
  • Proven in production as the VMM beneath Kata Containers in Azure AKS Pod Sandboxing (running on the Microsoft Hypervisor) and the hypervisor behind Fly.io's GPU machines

FAQ

What is Cloud Hypervisor?

Cloud Hypervisor is an open-source virtual machine monitor (VMM) written in Rust that runs modern cloud workloads on top of KVM or the Microsoft Hypervisor (MSHV), with minimal hardware emulation, fast boot, and a REST API for VM lifecycle control.

How much does Cloud Hypervisor cost?

It is free and open source, dual-licensed under Apache 2.0 and BSD-3-Clause and governed by the Linux Foundation. Costs come from the infrastructure you run it on and the orchestration you build around it.

How is Cloud Hypervisor different from Firecracker?

Both are Rust VMMs built on rust-vmm crates, but Firecracker optimizes for short-lived serverless microVMs with a deliberately tiny device model, while Cloud Hypervisor targets longer-lived, fuller VMs — adding PCI/GPU passthrough, device hotplug, live migration, UEFI firmware boot, qcow2 disks, and Windows guests.

Who uses Cloud Hypervisor in production?

Microsoft uses it as the VMM for Kata-based Pod Sandboxing on Azure Kubernetes Service, Fly.io uses it for GPU machines, and it is a supported hypervisor backend for Kata Containers and Hypeman.

Executive Summary

Cloud Hypervisor is an open-source virtual machine monitor (VMM) for modern cloud workloads — written in Rust, built on the rust-vmm crates, and able to run on either Linux KVM or the Microsoft Hypervisor (MSHV).[1] It boots a guest to userspace in under 100ms with direct kernel boot, keeps hardware emulation minimal, and exposes a REST API for programmatic VM lifecycle control.[2] The repository was created in April 2019 and carries 5,700+ GitHub stars and 680+ forks as of June 2026, with pushes as recent as June 10, 2026.[1]

Where Firecracker strips the device model to the bone for short-lived serverless functions, Cloud Hypervisor takes the same rust-vmm lineage in the other direction: long-lived, stateful VMs with CPU, memory, and PCI hotplug, VFIO physical device passthrough (including GPUs), live migration, UEFI firmware boot, and Windows guest support.[1][3] It is governed as a Linux Foundation project with contributors and supporters including Intel, Microsoft, ARM, AMD, Alibaba, ByteDance, Ampere, SAP, and Tencent Cloud,[2] and it runs in production as the VMM beneath Kata Containers in Azure AKS Pod Sandboxing[4] and behind Fly.io's GPU machines.[5]

AttributeValue
CreatorLinux Foundation project; backed by Intel, Microsoft, ARM, AMD, Alibaba, ByteDance, and others[2]
FoundedRepo created April 2019[1]
FundingN/A — foundation-governed open source
GitHub Stars5,700+ (June 2026)[1]
LicenseApache 2.0 + BSD-3-Clause (dual)[1]

Product Overview

Cloud Hypervisor is not a container runtime — it is the hypervisor layer that container-to-VM runtimes sit on. You launch the cloud-hypervisor binary with a guest kernel (direct boot) or a firmware image (UEFI boot), drive it over a REST API or the ch-remote CLI, and get a VM with its own kernel behind a hardware boundary.[1] "Cloud workloads" is a deliberate scoping decision: modern 64-bit guests with virtio paravirtualized I/O and no legacy device emulation, which keeps the attack surface small and boots fast.[1]

In the Container-to-VM Runtimes category, Cloud Hypervisor matters as a substrate with reach: it is the VMM Microsoft selected for Kata-based Pod Sandboxing on AKS — chosen for fast boot times in utility-VM use cases, runtime-configurable VM resources, and a minimal driver set tuned for container workloads[6] — and it is a supported hypervisor backend for both Kata Containers and Hypeman.[4][7]

Key Capabilities

CapabilityDescription
Fast bootUnder 100ms to userspace with direct kernel boot[2]
Dual hypervisor supportRuns on Linux KVM or Microsoft Hypervisor (MSHV)[1]
HotplugCPU, memory, and PCI device hotplug on live VMs[1]
Device passthroughVFIO physical device passthrough (GPUs included), via the modern iommufd subsystem as of v52.0[2]
Live migrationMachine-to-machine migration, with multi-connection TCP support in v52.0[2][8]
Snapshot/restoreVM snapshots with userfaultfd demand-paged restore[2]
Guest OS range64-bit Linux plus Windows 10 / Windows Server 2019[1]
Confidential computingAMD SEV-SNP confidential VM support on KVM[2]

Product Surfaces

SurfaceDescriptionAvailability
cloud-hypervisor binaryStatic prebuilt binaries for x86-64 and AArch64[1]GA
REST APIProgrammatic VM lifecycle control[2]GA
Distro packagesPackages for popular Linux distributions via the Open Build Service[1]GA

Technical Architecture

Cloud Hypervisor is a userspace VMM: the hypervisor itself is KVM (or MSHV on Microsoft platforms), and Cloud Hypervisor supplies the device model, API, and lifecycle management on top.[1] It is implemented in Rust on the shared rust-vmm crates — the same foundation as Firecracker and crosvm — with explicit goals of minimal emulation, low latency, low memory footprint, and a small attack surface.[1] I/O is paravirtualized via virtio with generic vhost-user device offload, and storage gained an asynchronous qcow2 backend built on io_uring in v52.0.[2]

Installation (prebuilt static binary):

wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/latest/download/cloud-hypervisor-static
chmod +x cloud-hypervisor-static

Key Technical Details

AspectDetail
DeploymentLinux host on KVM (kernel 5.13+ recommended) or Microsoft Hypervisor (MSHV)[1]
Architecturesx86-64 and AArch64; riscv64 experimental[1]
Guests64-bit Linux, Windows 10 / Server 2019[1]
IntegrationsKata Containers hypervisor backend (Azure AKS Pod Sandboxing), Hypeman backend, Fly.io GPU machines[4][5]
Open SourceYes — Apache 2.0 + BSD-3-Clause[1]

The release cadence is steady: v52.0 shipped May 14, 2026 — the project's 52nd major release since 2019 — while patch releases (v51.2, v50.2) are maintained on prior branches in parallel.[8][1]

Strengths

  • Broadest device model in the rust-vmm family — VFIO passthrough (including GPUs), CPU/memory/PCI hotplug, live migration, UEFI firmware boot, and qcow2 disks; features Firecracker deliberately excludes and will most likely never add[3]
  • Production-proven at hyperscale — the VMM beneath Kata-based Pod Sandboxing on Azure Kubernetes Service, running on the Microsoft Hypervisor with nested VMs[4][6]
  • The GPU-capable microVM choice — Fly.io runs its GPU machines on Cloud Hypervisor rather than Firecracker precisely because of PCI passthrough[5]
  • Vendor-neutral governance — Linux Foundation project with contributors across Intel, Microsoft, ARM, AMD, Alibaba, ByteDance, Ampere, SAP, and Tencent Cloud; no single-vendor roadmap risk[2]
  • Still fast and small — under 100ms boot to userspace with minimal emulation and a Rust codebase focused on a small attack surface[2]
  • Only major Rust VMM with MSHV support — runs on the Microsoft Hypervisor as well as KVM, which is why it fits Azure's stack[1][6]
  • Active, regular releases — 52 major versions since 2019, v52.0 in May 2026 adding SEV-SNP confidential VMs, iommufd VFIO, and multi-connection live migration[8][2]

Cautions

  • Not a runtime — a building block — there is no docker run equivalent; you bring orchestration yourself or adopt a layer like Kata Containers or Hypeman on top[7]
  • Bigger codebase than Firecracker — roughly 106,000 lines of Rust versus Firecracker's ~83,000 as measured in March 2026; the richer device model is a real (if modest) attack-surface trade-off[3]
  • Smaller community by the numbers — 5,700+ stars versus Firecracker's 34,800+; fewer tutorials, wrappers, and third-party integrations exist[1]
  • Not the density king — comparisons position Firecracker as the leaner pick for short-lived, high-density serverless workloads; Cloud Hypervisor targets longer-lived, stateful VMs[7][3]
  • Linux-host, 64-bit-only scope — requires KVM (kernel 5.13+ recommended) or MSHV; no macOS host support and no 32-bit or legacy guest support[1]
  • Fast-moving major versions — 52 major releases in seven years means consumers must track upgrades, though parallel patch branches (v50.2, v51.2) soften the burden[1]

Pricing & Licensing

TierPriceIncludes
Cloud HypervisorFreeFull VMM — all features, prebuilt binaries, distro packages[1]

Licensing model: Free and open source, dual-licensed under Apache 2.0 and BSD-3-Clause, governed by the Linux Foundation — no commercial tier exists.[1][2]

Hidden costs: Engineering effort is the real price — building image pipelines, networking, and orchestration around a raw VMM is substantial work, which is why most teams consume it through Kata Containers, Hypeman, or a cloud platform.[7]

Competitive Positioning

Direct Competitors

CompetitorDifferentiation
FirecrackerAWS's minimal microVM VMM for serverless; faster ecosystem but no PCI/GPU passthrough, raw-only disks, Linux-direct-boot-only — Cloud Hypervisor adds all three[3]
Kata ContainersNot a rival but a consumer — an OCI runtime that can use Cloud Hypervisor (as Azure does), QEMU, or Firecracker underneath[4]
HypemanDocker-like UX layer that runs containers in VMs with Cloud Hypervisor as one of its supported hypervisor backends
QEMUMaximum device breadth and maturity, but a far larger C codebase and attack surface; Cloud Hypervisor keeps the modern subset in Rust[7]
crosvmGoogle's Rust VMM from ChromeOS, sharing rust-vmm crates; tuned for ChromeOS rather than cloud server workloads[1]

When to Choose Cloud Hypervisor Over Alternatives

  • Choose Cloud Hypervisor when: You need VM-level isolation plus GPU/PCI passthrough, hotplug, live migration, Windows guests, or longer-lived stateful VMs — with foundation governance instead of a single vendor[3]
  • Choose Firecracker when: You run masses of short-lived, ephemeral Linux microVMs and want the smallest possible device model and the largest ecosystem[7]
  • Choose Kata Containers when: You want Kubernetes-native VM isolation without operating a VMM directly — and note it may run Cloud Hypervisor for you underneath[4]
  • Choose Hypeman when: You want Docker-like commands and multi-hypervisor flexibility rather than programming a VMM's REST API

Ideal Customer Profile

Best fit:

  • Platform teams building VM-isolated container or sandbox infrastructure that needs GPUs or other PCI devices passed through[5]
  • Operators of long-lived, stateful guest VMs who need hotplug, live migration, or snapshot/restore[2]
  • Organizations on Microsoft Hypervisor / Azure-aligned stacks, where it is the proven Kata VMM[4]
  • Teams with open-source governance requirements who prefer a Linux Foundation project over a vendor-owned VMM[2]
  • Confidential-computing workloads using AMD SEV-SNP[2]

Poor fit:

  • Teams wanting a turnkey container runtime — this is a hypervisor layer, not a docker run replacement[7]
  • Pure serverless platforms spawning thousands of identical, ephemeral Linux functions, where Firecracker's minimalism wins[7]
  • macOS-host or 32-bit/legacy-guest use cases[1]

Viability Assessment

FactorAssessment
Financial HealthStrong — Linux Foundation governance with corporate backing from Intel, Microsoft, ARM, AMD, Alibaba, ByteDance, Ampere, SAP, and Tencent Cloud[2]
Market PositionChallenger — 5,700+ stars trails Firecracker's 34,800+, but it owns the feature-rich end of the Rust VMM spectrum and ships inside Azure[1][4]
Innovation PaceActive — v52.0 (May 2026) added SEV-SNP, iommufd passthrough, multi-connection live migration, and async qcow2; pushes as recent as June 10, 2026[8][1]
Community/EcosystemSolid — 680+ forks, Slack and mailing-list community, distro packaging via OBS, plus downstream consumers in Kata, Hypeman, and Fly.io[1][5]
Long-term OutlookPositive — multi-vendor foundation governance and production roles at Microsoft and Fly.io make abandonment risk low

Cloud Hypervisor occupies a durable position: it is the only Rust VMM that pairs Firecracker-class boot speed with a full-featured device model and multi-vendor foundation governance. Its star count understates its importance — it is infrastructure consumed indirectly, through Kata on AKS and platforms like Fly.io, rather than a tool developers star and install directly.[4][5]

Bottom Line

Cloud Hypervisor is the "grown-up Firecracker" of the container-to-VM stack: same Rust and rust-vmm DNA, same sub-100ms boots and minimal-emulation philosophy, but with the GPU passthrough, hotplug, live migration, and Windows support that real platform workloads eventually demand.[3][2] Linux Foundation governance with Intel, Microsoft, ARM, Alibaba, and ByteDance behind it removes the single-vendor concern that critics raise about Amazon-governed Firecracker.[2][3]

Recommended for: Platform engineers building VM-isolated infrastructure that needs more than ephemeral Linux microVMs — GPU workloads, stateful VMs, live migration, Windows guests, or MSHV/Azure-aligned stacks.

Not recommended for: Teams wanting a ready-made container runtime (use Kata or Hypeman on top), or pure high-density serverless platforms where Firecracker's smaller footprint and larger ecosystem fit better.

Outlook: Expect continued confidential-computing depth (SEV-SNP shipped in v52.0) and steady major releases. As AI infrastructure pushes GPU passthrough into the isolation layer, Cloud Hypervisor's differentiation versus Firecracker gets more valuable, not less.

Research by Ry Walker Research • methodology

Sources

Share on XShare on LinkedIn