Learn Cloud Hypervisor - Core Concepts & Main Architecture

#Introduction

After understanding the history and motivation behind Cloud Hypervisor in episode 1, now we dissect how it works from the inside. Architecture determines everything: why boot is so fast, why the binary is small, and why devices can be hotplugged. In episode 2 we trace the anatomy of this VMM — from the process running on the host to the ring buffers that connect it to the guest.

Think of Cloud Hypervisor like an airport traffic controller: it doesn't fly the planes (that's the job of the guest OS inside the VM), but it manages the in/out paths (vCPU), the cargo gates (virtio-block), the network runways (virtio-net), and the control tower (KVM's vCPU scheduler). All of this coordination happens through a single process on the host.

#Architecture: A Rust Single-Binary VMM

#One Process, Many Roles

Cloud Hypervisor is a single-binary VMM: the entire VMM — vCPU loop, device model, and memory management — lives in one Rust process. The advantages: easy to deploy (one file), small memory footprint, and easier to sandbox (we discuss Landlock in episode 12). Unlike QEMU, which spawns many helpers, Cloud Hypervisor handles everything itself.

The basic structure looks roughly like this:

cloud-hypervisor (proses host)
├── vCPU threads        → dikelola KVM, menjalankan ring guest
├── device model        → virtio devices + MMIO/PIO trap handler
├── memory manager      → guest RAM, hugepages, shared memory
└── control plane       → menerima perintah (hotplug, snapshot, dll.)

#KVM and MSHV Backends

This process doesn't execute guest instructions directly. It asks the KVM kernel to create vCPUs and a VM via ioctls (from the kvm-ioctls crate). KVM acts as the accelerator: guest code runs directly on the CPU (ring 1 VMX/SVM), and the moment an event needs VMM handling (port I/O, MMIO, hypercall), the CPU performs a VM-exit and control returns to the VMM process.

cat /proc/misc | grep kvm
lsmod | grep kvm

In addition to KVM, Cloud Hypervisor supports the Microsoft Hypervisor (MSHV) backend for Windows/Hyper-V platforms. However, in this series we focus on KVM, the main backend for Linux. On aarch64, Cloud Hypervisor uses KVM on Arm hosts that support virtualization, and riscv64 support is still experimental.

#Virtio Device Model

#Virtio: The Paravirtualized Device Standard

Instead of emulating physical devices, Cloud Hypervisor presents virtio devices. The concept: guest and host share virtqueues (ring buffers) in shared memory. The guest produces requests (e.g., "write this block to disk"), the host consumes them, then replies. Because there's no physical hardware emulation, overhead is much lower.

Supported devices include:

• virtio-net: a virtual NIC for VM traffic.
• virtio-blk: a block disk (raw, qcow2, and others).
• virtio-pmem: persistent memory presented as a non-volatile device.
• virtio-fs: filesystem sharing with the host (via virtiofsd).
• virtio-vsock: host↔guest sockets without using the network.
• virtio-rng: entropy for the guest.

cloud-hypervisor \
  --disk path=ubuntu.raw \
  --net tap=ch0,ip=192.168.100.1 \
  --rng

--rng presents virtio-rng so the guest never runs out of entropy — a problem that often makes cryptographic applications hang in VMs without a good random source.

#vhost-user: Offloading to an External Daemon

For higher performance, Cloud Hypervisor can hand off data plane processing to an external daemon via the vhost-user protocol. Daemons such as vhost-user-net or virtiofsd hold direct access to the device/fd, while the VMM only manages control. This reduces VM-exit overhead because the data plane doesn't need to bounce back and forth to the VMM process. We cover the practice in episode 7.

#Supporting Components

Beyond the main binary, the Cloud Hypervisor ecosystem has three important components:

#rust-hypervisor-firmware

rust-hypervisor-firmware (also called hypervisor-fw) is a minimal Rust-based firmware for booting Linux guests. It performs initial setup (GDT, page tables) then jumps straight to the kernel — much faster than a full firmware. It's suitable for direct boot without a boot-loader filesystem.

#edk2 UEFI: CLOUDHV.fd

To boot a full OS such as Ubuntu with GRUB, or Windows, you need UEFI firmware based on edk2 — provided as the CLOUDHV.fd file. This is an edk2 variant maintained specifically for Cloud Hypervisor. The differences from upstream edk2 are covered in episode 15, especially for aarch64.

#Device Model: virtio-*

All devices presented to the guest (virtio-net, virtio-blk, etc.) are implemented inside the binary as part of the device model. Because it's Rust-based and shares crates with other rust-vmm projects (kvm-ioctls, vm-memory, virtio-queue), the implementation is cross-tested with Firecracker and crosvm — details in episode 21.

#The Conceptual VM Run Flow

The logical sequence when cloud-hypervisor --kernel vmlinux --disk path=disk.raw is executed:

1. The VMM process reads the configuration and opens /dev/kvm.
2. The VMM creates the VM and vCPUs via KVM ioctls.
3. Guest memory is allocated (from a memory file or hugepages).
4. virtio devices are created, and ring buffers are wired to guest memory.
5. The guest kernel is loaded (direct boot via PVH) or firmware is run.
6. The VMM enters its loop: running vCPUs, handling VM-exits (I/O, MMIO), and serving control plane commands.

#Conclusion

Key takeaways:

• Cloud Hypervisor is a Rust single-binary VMM: vCPU, device model, and memory management in one process.
• KVM (or MSHV) is the backend that executes the guest; the VMM handles VM-exits and devices.
• All devices use virtio: net, block, pmem, fs, vsock, rng.
• vhost-user offloads the data plane to an external daemon for high performance.
• rust-hypervisor-firmware for fast boot, CLOUDHV.fd (edk2) for full OS/Windows.
• Shared rust-vmm crates make the device implementation cross-tested with Firecracker and crosvm.

In the next episode, episode 3, we'll install and build Cloud Hypervisor — downloading the v53.0 release binary, or compiling from source with cargo build --release, granting setcap cap_net_admin+ep, and verifying everything with cloud-hypervisor --version. Get your Rust toolchain ready!