Learn Cloud Hypervisor - Pre-Requisites Skill & Setup Environment

#Introduction

Welcome to the Learn Cloud Hypervisor series! This series will take you through mastering Cloud Hypervisor — the modern Rust-based Virtual Machine Monitor (VMM) that runs cloud VMs (Linux/Windows) with fast boot, a small footprint, and support for hotplug, snapshot/restore, and live migration. There are 23 episodes in total, arranged into six phases, from conceptual foundations all the way to production readiness as a Kata Containers backend.

Before you touch cloud-hypervisor --kernel ..., there are foundational skills and software you must have. Why do these prerequisites matter? Because Cloud Hypervisor works at the kernel layer: it uses KVM, builds virtual devices (virtio), and manages TAP networking. Without understanding these layers, you'll struggle to diagnose problems when a VM fails to boot or a network won't connect.

Episode 0 is your roadmap: we'll make sure the foundational skills are in place, prepare your host, install the tooling, and verify the environment for the first time. Once this episode is done, the rest of the series can be followed comfortably.

#Foundational Skills You Must Master

#Linux Administration and KVM

Cloud Hypervisor is a type-2 VMM that leverages KVM on the host. You need to understand how the Linux kernel works: the kvm and kvm_intel/kvm_amd modules, the concept of vCPU, and why hypercalls are necessary. First, check whether your host supports virtualization:

grep -E "(vmx|svm)" /proc/cpuinfo | head -5
ls -l /dev/kvm

A /dev/kvm device means KVM is active. If it's missing, enable virtualization in the host BIOS/UEFI or use a cloud instance that supports nested virtualization (we cover this in episode 19).

#Networking: TAP, Bridge, and vhost

VMs need networking. Cloud Hypervisor uses TAP devices — virtual interfaces that connect a VM to the host's network stack. You should understand the concept of a bridge (connecting multiple TAPs), routing, and a bit of iptables/firewall. These concepts are used continuously from episode 7 onward.

#Virtualization Concepts: VMM and Guest OS

Understand the difference between a VMM (the software that manages a VM, e.g., Cloud Hypervisor) and a guest OS (the operating system running inside the VM). Also understand the term virtio — the paravirtualized device standard that lets disks, NICs, and other devices share ring buffers with the guest. In episode 2 we dig deeper into its architecture.

#Software and Hardware to Prepare

#A Host with KVM

Use an x86_64 or aarch64 host with a modern Linux kernel and KVM. Make sure you have enough disk space (at least 20 GB for the cloud image and the VM disk). Check the basic specs:

uname -m
uname -r
nproc
free -h

#The Cloud Hypervisor Binary

Download the prebuilt binary from the official GitHub releases page. For this series we use v53.0 (released 12 July 2026). Choose the file that matches your architecture:

wget https://github.com/cloud-hypervisor/cloud-hypervisor/releases/download/v53.0/cloud-hypervisor-static-x86_64
chmod +x cloud-hypervisor-static-x86_64
sudo mv cloud-hypervisor-static-x86_64 /usr/local/bin/cloud-hypervisor

Alternatively, you can build from source with cargo build --release — we do both in episode 3.

#Kernel and Cloud Image

You need a Linux kernel for direct boot and a cloud image as the guest disk. The kernel can be a vmlinux (from a distribution or a manual build), while the cloud image can be, for example, the Ubuntu cloudimg from https://cloud-images.ubuntu.com. We'll download and configure them in more detail in episodes 4 and 9.

#Firmware

To boot a full OS (Ubuntu with GRUB, or Windows), Cloud Hypervisor needs firmware: rust-hypervisor-firmware (hypervisor-fw) or CLOUDHV.fd (UEFI based on edk2). Get both from the official releases page.

#setcap: Permission for TAP

Cloud Hypervisor needs to create TAP devices — an operation that requires CAP_NET_ADMIN. Instead of running everything as root, give the binary a specific capability:

sudo setcap cap_net_admin+ep /usr/local/bin/cloud-hypervisor

setcap cap_net_admin+ep adds effective and permitted CAP_NET_ADMIN to the binary, allowing it to create TAPs without being fully root. This is a better security practice and we'll discuss it further in episode 13.

#Verifying the Environment

Before moving on to episode 1, run a thorough verification:

cloud-hypervisor --version
ls -l /dev/kvm
grep -E "(vmx|svm)" /proc/cpuinfo | wc -l
getcap /usr/local/bin/cloud-hypervisor

All four commands must succeed. cloud-hypervisor --version should print the version (e.g., v53.0), and getcap should show cap_net_admin=ep.

#Prerequisites Summary

Here's a summary of what you prepared in episode 0:

• Linux skills: basic administration, KVM, TAP/bridge networking, and VMM concepts.
• Host: x86_64/aarch64 with /dev/kvm active and a modern kernel.
• Binary: cloud-hypervisor v53.0 installed and granted setcap cap_net_admin+ep.
• Guest assets: a Linux kernel, a cloud image, and firmware (hypervisor-fw/CLOUDHV.fd).

If anything is missing, stop and complete it before moving on. The 22-episode journey ahead will be much smoother with this solid foundation.

#Conclusion

Key takeaways:

• Cloud Hypervisor is a Rust-based VMM that depends entirely on KVM.
• Linux administration skills, TAP/bridge networking, and virtio concepts are its foundation.
• Prepare a host with /dev/kvm, the cloud-hypervisor binary, a kernel, a cloud image, and firmware.
• Use setcap cap_net_admin+ep so TAPs can be created without full root.
• Always verify with cloud-hypervisor --version and check /dev/kvm.

In the next episode, episode 1, we'll discuss the history, background, and why you need Cloud Hypervisor — from Intel's 2019 initiative, open governance with AMD, Arm, and Microsoft, the first LTS release v28 (November 2022), to the real problems it solves: a fast, minimal, and secure VMM for modern cloud workloads. Make sure your environment is ready, because the Learn Cloud Hypervisor journey has just begun!