Cloud Parts

Cloud Hypervisor

A Rust virtual machine monitor for modern cloud VMs on KVM or Microsoft’s hypervisor: virtio devices only, plus hotplug, VFIO passthrough, live migration, snapshots and Windows guests.

What it is
Hypervisors
Used for
MicroVMs
Type
Open source
Made by
Cloud Hypervisor project (Linux Foundation), started at Intel
License
Apache 2.0 and BSD-3-Clause
Facts checked
11 October 2026
Website Source code

What it is

Cloud Hypervisor is a virtual machine monitor (VMM): the user-space program that creates a VM, emulates its devices and runs its vCPUs on a kernel hypervisor. It runs on Linux’s KVM or on the Microsoft Hypervisor (MSHV), the hypervisor underneath Hyper-V, where Linux runs as the root partition. It targets the VMs a cloud provider rents out: 64-bit guests whose I/O goes through paravirtualized virtio devices, with no need for legacy PC hardware. The device model is a handful of platform devices (a serial port, an RTC, an I/O APIC, ACPI shutdown and reboot) plus virtio block, network, console, IOMMU, persistent memory, RNG and vsock devices on a virtio-pci transport, and vhost-user devices that offload disk, network or filesystem work to another process. It boots a kernel directly (a PVH vmlinux or a bzImage) or a firmware: Rust Hypervisor Firmware, or an edk2 UEFI build that Windows guests need. It is written in Rust from the rust-vmm crates it shares with Firecracker and crosvm, and much of its code started in those two projects.

Unlike Firecracker, which is cut down for serverless functions, Cloud Hypervisor aims to be a general-purpose VMM. Each process runs one VM and is driven by its command line or a REST API (OpenAPI 3.0) on a Unix socket, which the bundled ch-remote tool calls. Through that API you can add vCPUs (x86 only) and memory to a running guest, hot-plug virtio disks, network cards, filesystems and vsock devices, pass host PCI devices through with VFIO, pause, snapshot and restore a VM, and live-migrate it over TCP, or over a Unix socket on the same host to upgrade the VMM with little downtime. Windows 10, Windows 11 and Windows Server guests run under KVM from UEFI images with virtio drivers. x86-64 and AArch64 (with a GICv3 interrupt controller) are the main architectures, and riscv64 is experimental.

Intel started the project in 2019 and it moved to the Linux Foundation in December 2021, backed by Alibaba, Arm, ByteDance, Intel and Microsoft. Kata Containers offers it as one of its VMMs, and Azure Kubernetes Service builds Pod Sandboxing from Kata Containers, Cloud Hypervisor and the Hyper-V hypervisor on Azure Linux hosts. Versions are numbered by major release, aiming for one about every six weeks; in practice they have come about every two months (v46.0 in May 2025 to v53.0 in July 2026). Each major release gets bug fixes for two cycles, about 12 weeks, and then reaches end of life.

Why teams pick it

  • A small, modern codebase: memory-safe Rust, a minimal virtio-based device model and no legacy devices, with the CLI, REST API and guest-visible devices covered by a stability policy (two major releases’ notice before breaking changes)
  • The lifecycle features general-purpose cloud VMs need: CPU, memory and device hotplug, VFIO passthrough, snapshot and restore, and live migration, including same-host migration for VMM upgrades
  • Runs Windows as well as Linux guests, on two hypervisors: KVM, or MSHV under a Linux root partition
  • Multi-vendor and in production use: a Linux Foundation project, a VMM option in Kata Containers, and part of AKS Pod Sandboxing

Watch out for

  • A short support window: each major release gets fixes for about 12 weeks, and snapshots and live migration don’t work across major versions, so upgrades need planning
  • A building block, not a platform: you bring the kernel or firmware, disk images, tap devices and orchestration, or use a layer such as Kata Containers
  • Modern guests only: 64-bit, virtio drivers required, Windows only from UEFI images, CPU hotplug on x86 only, and live migration needs shared memory or huge pages
  • Advanced hardware support is thinner than QEMU’s: TDX, vfio-user and vDPA are experimental, and Kata’s docs list no GPU, TDX or SEV-SNP support for its Cloud Hypervisor runtime and point to QEMU for those

Alternatives

What all hypervisors have in common →
KVM (Kernel-based Virtual Machine)Open sourceThe hypervisor built into the Linux kernel: it runs guest code directly on the CPU through `/dev/kvm`, and leaves device emulation to a user-space program such as QEMU or Firecracker.libvirtOpen sourceA stable API, daemon and `virsh` command line for managing virtual machines, storage and networks, with drivers for QEMU/KVM, Xen, LXC, Cloud Hypervisor, VMware ESX, Hyper-V and more.Microsoft Hyper-VCommercialMicrosoft’s type-1 hypervisor, built into Windows Server and Windows 10 and 11 Pro and Enterprise: a thin hypervisor under a Windows root partition, which also underpins Azure’s hypervisor and Windows features like VBS, WSL 2 and Windows Sandbox.Oracle VirtualBoxOpen sourceOracle’s free, open-source desktop hypervisor: a type-2 hypervisor that runs VMs as an application on Windows, macOS, Linux and Solaris, scriptable with `VBoxManage` and the default provider for Vagrant.Proxmox Virtual EnvironmentOpen sourceA Debian-based server platform from Vienna that runs KVM virtual machines and LXC containers, with clustering, high availability, Ceph and ZFS storage, backups and a web interface in one free ISO.QEMUOpen sourceThe open-source machine emulator and virtualizer: it emulates whole computers in software, or runs them at native speed on a hypervisor such as KVM, and supplies the virtual devices either way.VMware ESXiCommercialVMware’s bare-metal hypervisor (called ESX again since VCF 9), whose own kernel runs VMs directly on servers while vCenter adds vMotion, HA, DRS and vSAN; since Broadcom bought VMware in 2023 it is sold only as per-core subscriptions.Xen Project hypervisorOpen sourceThe open-source type-1 hypervisor from Cambridge that ran the first Amazon EC2 instances: a small microkernel-style core that boots first, with drivers and management in a privileged VM called dom0.

How it fits with other technologies

Boot a VM, then grow it and snapshot it through the API socket (from the project docs, not run here: needs a Linux host with KVM) · bash

sudo setcap cap_net_admin+ep ./cloud-hypervisor

./cloud-hypervisor \
  --api-socket /tmp/ch.sock \
  --kernel ./vmlinux \
  --cmdline "console=hvc0 root=/dev/vda1 rw" \
  --disk path=focal-server-cloudimg-amd64.raw,image_type=raw \
  --cpus boot=2,max=4 \
  --memory size=1024M,hotplug_size=4096M \
  --net "tap=,mac=,ip=,mask="

# from another shell: hot-add two vCPUs and grow RAM to 3 GiB
./ch-remote --api-socket /tmp/ch.sock resize --cpus 4
./ch-remote --api-socket /tmp/ch.sock resize --memory 3G

# pause, then save the VM's state to a directory that already exists
./ch-remote --api-socket /tmp/ch.sock pause
./ch-remote --api-socket /tmp/ch.sock snapshot file:///var/lib/ch/snap1

See it in a real stack

No architecture uses Cloud Hypervisor yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2026

Intel started Cloud Hypervisor in 2019. Arjan van de Ven, an Intel Fellow and the project’s founding technical sponsor, later said the aim was “a more secure and updated VMM to optimize for modern cloud workloads”, with fewer device models and a memory-safe language. Instead of starting from nothing, the team built on the rust-vmm crates and on code from Firecracker and crosvm, the Rust VMMs from AWS and Google. Version 0.1.0 came out in July 2019 from Intel’s GitHub organization, already with VFIO device assignment, virtio-fs file sharing, virtio-pmem and direct boot of distribution bzImage kernels.

Where Firecracker trimmed a VMM down for short-lived serverless functions, Cloud Hypervisor aimed at the full range of cloud VMs. Version 0.10.0 (September 2020) added Windows guests. Microsoft, which since 2020 has been publishing open-source pieces for running Linux as the root partition of its own hypervisor, became one of the backers, and Cloud Hypervisor gained MSHV as a second backend next to KVM. On December 8, 2021 the project moved to the Linux Foundation, supported by Alibaba, Arm, ByteDance, Intel and Microsoft.

Today Kata Containers ships a Cloud Hypervisor configuration, and Azure Kubernetes Service uses it with Kata and the Hyper-V hypervisor for Pod Sandboxing. The project keeps a fast cadence of numbered major releases, reaching v53.0 in July 2026.

Why it’s built this way

Build on rust-vmm instead of from scratch
Rust’s memory and thread safety suit a security boundary, and importing shared crates (and code from Firecracker and crosvm) let three VMMs share components rather than each reimplementing KVM wrappers, memory handling and virtio devices.
Only modern cloud guests: 64-bit, virtio, no legacy devices
Cloud customers run modern operating systems whose I/O already goes through paravirtualized devices. Dropping old PC hardware keeps emulation, attack surface, memory footprint and latency low.
General-purpose rather than serverless-only
The README sets it apart from Firecracker and crosvm by aiming at cloud workloads in general, not just containers, serverless or client devices. That is why it carries CPU, memory and PCI hotplug, VFIO, live migration and Windows support.
More than one hypervisor backend
Running on MSHV as well as KVM lets the same VMM serve Linux hosts and hosts where Linux is the root partition of Microsoft’s hypervisor, as in AKS Pod Sandboxing.

Timeline

  1. 2019

    Intel releases v0.1.0 in July, with VFIO, virtio-fs and virtio-pmem

  2. 2020

    Microsoft begins releasing components for Linux as root partition on its hypervisor; v0.10.0 adds Windows guests (September)

  3. 2021

    Moves to the Linux Foundation (December 8), backed by Alibaba, Arm, ByteDance, Intel and Microsoft

  4. 2025

    Major releases v46 to v50 arrive roughly every two months

  5. 2026

    v53.0 released in July

Sources16 · facts checked 11 October 2026

Improve this page on GitHub