Learn Cloud Hypervisor - History, Background & Why You Need It

#Introduction

With our environment ready in episode 0, it's now time to understand why Cloud Hypervisor exists. Every major technology is born from a real problem, and Cloud Hypervisor is no exception. In episode 1 we trace its history from Intel's 2019 initiative, its evolution into an open governance project, to the concrete reasons why this Rust-based VMM is needed for modern cloud workloads.

The questions we'll answer: what was wrong with QEMU that led cloud engineers to build a new VMM? Why choose Rust? And why was it ultimately adopted as one of Kata Containers' official backends? These answers matter because they determine when you should choose Cloud Hypervisor in production.

#History and Background

#Born from the Needs of Cloud and Kata Containers

Cloud Hypervisor was initiated by Intel in 2019. The context at the time: the Kata Containers project (container isolation via VMs) and serverless functions needed a VMM that could boot fast and stay resource-efficient — yet QEMU, a very complete VMM, was considered too heavy and complex for those scenarios. The solution wasn't trimming QEMU, but building a new "cloud-first" VMM.

Its design principle was simple: little, focused, and secure. Focus on modern cloud workloads (Linux/Windows) with a modern virtio device model, rather than emulating decades-old legacy devices. From there, Cloud Hypervisor was born as an open source project under the Apache 2.0 license.

#Open Governance

Since 2021 the project transformed into open governance with contributors from many companies. Its founding charter involves Intel, AMD, Arm, and Microsoft — all four now contribute actively. This matters: because it's governed openly, Cloud Hypervisor can't be steered for a single vendor's benefit, and multi-architecture support (x86_64 and aarch64) becomes a real priority, not just a promise.

#The First LTS Release: v28

In November 2022, Cloud Hypervisor released its first LTS (Long Term Support) version: v28, with a support period of 18 months. This LTS model mirrors enterprise distribution practice: a stable version maintained long-term for production, while monthly minor releases keep delivering new features. Notably, Cloud Hypervisor's LTS guarantees live migration between point-releases — for example from v28.0 to v28.1 — so production users can apply security upgrades without sacrificing operational continuity. We dive deeper into live migration in episode 11.

#Why You Need Cloud Hypervisor

#Modern Virtio Without the Bloat

QEMU supports hundreds of legacy devices (IDE, PS/2, old VGA, etc.) that are barely used in the cloud. Cloud Hypervisor takes the opposite path: it mirrors QEMU's modern virtio device model — staying compatible with standard guest drivers — but refuses to include ancient devices. The result is far less code, a smaller attack surface, and a slimmer binary.

ls -lh /usr/local/bin/cloud-hypervisor /usr/bin/qemu-system-x86_64

In general, the static Cloud Hypervisor binary is in the tens of MB range, while a full QEMU is much larger and depends on many libraries. This small size also means faster process startup and lower memory usage.

#Fast Boot and Small Footprint

Because there's no legacy BIOS firmware emulation and the device set is minimal, a direct Linux boot (without GRUB) can complete in milliseconds to seconds, rather than tens of seconds. The small memory footprint raises VM density per host — something serverless platforms love.

#Hotplug, Snapshot/Restore, and Live Migration

Cloud Hypervisor supports CPU and memory hotplug (adding resources without restarting the VM), snapshot/restore (saving VM state to disk and restoring it later), and live migration (moving a VM between hosts without downtime). These three features are operational cloud requirements that usually only large VMMs have. We'll practice them in episodes 8, 10, and 11.

#Kata Containers Backend: kata-clh

One of its most significant uses is as a Kata Containers backend via the kata-clh runtime. Every pod in Kubernetes is isolated inside a lightweight Cloud Hypervisor VM — VM security with container agility. We break down the details in episode 18.

#Position in the VMM Ecosystem

To position Cloud Hypervisor, remember the three main currents of VMMs:

• QEMU/KVM: a complete VMM with broad compatibility, but complex and heavy.
• Firecracker: AWS's minimal microVM for serverless functions — speed over features.
• Cloud Hypervisor: the modern compromise — a feature-rich VMM (hotplug, migration, passthrough) with a minimalist Rust philosophy.

Cloud Hypervisor fills the space the other two leave behind: feature-rich enough for full VMs yet fast and small enough for microVM workloads. In episode 22 we'll compare it thoroughly with Firecracker, QEMU, crosvm, and Kata Containers.

#Conclusion

Key takeaways:

• Cloud Hypervisor was born from the needs of cloud/Kata Containers: a fast, minimal, and secure VMM.
• Initiated by Intel (2019), now open governance with AMD, Arm, and Microsoft as contributors.
• First LTS v28 (Nov 2022) with 18 months of support and live migration between point-releases.
• Modern virtio without bloat, fast boot, small footprint, hotplug, snapshot/restore, and live migration.
• Written in Rust, safe from the memory-safety bug class common in C-based VMMs.

In the next episode, episode 2, we'll dissect the core concepts and main architecture of Cloud Hypervisor — how this single-binary VMM works on top of KVM, how virtio devices (net, block, pmem, fs, vsock, rng) are built, the role of vhost-user for offload, and the functions of rust-hypervisor-firmware and CLOUDHV.fd. This is the anatomy that will explain every flag we use in the episodes ahead.