Modern cloud guests get less legacy hardware
Cloud Hypervisor is built for cloud images and current operating systems rather than decades of PC compatibility. Its device model centers on virtio, with support for CPU, memory, PCI, and several virtio-device hotplug paths. The documented guests are 64-bit Linux, Windows 10, and Windows Server 2019. x86-64 and AArch64 are the main host architectures; RISC-V support is experimental and has limited functionality.
The project is large despite its minimal-emulation goal. Our checkout at commit ae44c29 contained 441 files and about 181,775 source lines. It imports shared Rust VMM crates and implements boot, memory, devices, migration, API handling, sandbox controls, disk formats, and architecture-specific paths. Choosing less legacy emulation reduces one kind of complexity, but hotplug and migration add their own state and compatibility work.
Booting requires firmware or a suitable guest kernel
The recommended trial starts with a prebuilt static binary. A VM can boot through Rust Hypervisor Firmware or the project's edk2 UEFI build, or directly from a compatible kernel. On x86-64, direct boot accepts a PVH-enabled ELF kernel or a bzImage. A cloud disk often needs conversion to raw format and a cloud-init image for initial credentials and networking. Those artifacts are outside the VMM binary.
Our dependency install took 13 seconds for 237 Rust packages, while compilation took 176 seconds. A running VM also needs KVM or MSHV support and host permissions. The README recommends host kernel 5.13 and says most CI runs on 5.15. Example tap networking grants cap_net_admin to the binary. Production teams should narrow capabilities and device access around the exact network and passthrough design rather than copy a development command.
What happened when we ran it
Our unprivileged Rust Debian sandbox installed successfully in 13 seconds and built successfully in 176 seconds. The test command then failed with exit code 101 after 205 seconds. Cargo reported 295 passed and 28 failed out of 323. The container had 3 CPUs, 12 GB of RAM, no secrets, and the measured commit ae44c29.
The final log names failures in QCOW, raw, and VHD io_uring backend tests, along with async io_uring queue, duplicate user-data, and in-flight-operation cases. Cargo's summary says to rerun with -p block --lib. The log tail does not establish why those 28 tests failed, so we will not blame container privilege, kernel support, or a code defect without another run that isolates the condition.
Cross-version migration is outside the guarantee
The README promises notice before breaking command-line or API changes, with a minimum of 2 major releases. It also draws a firm boundary: snapshots cannot be restored across versions, and live migration is unsupported between different versions. TDX, vfio-user, and vDPA are called experimental. A fleet therefore needs image and VMM version coordination before maintenance, rollback, or host evacuation is planned.
Our 205-second test step did not exercise a pair of hosts or complete a migration. Release v53.0 adds an external snapshot and restore daemon, postcopy migration, on-demand paging, and mutual TLS for migration data. Those are meaningful operator features, but they increase the number of kernel interfaces, file descriptors, network paths, and failure states that must be rehearsed. Pin the VMM and firmware together, then test rollback with the same release.
Storage and sandbox details deserve targeted tests
The 28 failing tests cluster in the block library's io_uring paths according to the supplied names. They cover dispatch preservation after cloning, batched requests, logical-size boundaries, queue saturation, and draining operations during drop. That is exactly the area to rerun on the intended host because a cloud VMM's usefulness depends on correct disk behavior under concurrency and error conditions.
The successful 176-second build cannot replace that evidence. Issue 8796 separately reports that vhost-user block and network devices do not establish a backend request channel, so a backend disk resize cannot notify the guest. Issue 8793 reports that rebooting a VM with a serial Unix socket fails when Landlock is enabled. These reports concern different paths and should remain separate in acceptance tests.
Architecture support is intentionally uneven
AArch64 requires hardware with a GICv3 interrupt controller. The README points to a long-running issue for feature differences between x86-64 and AArch64, while RISC-V remains experimental. Issue 8716 says SMBIOS values accepted on AArch64 are not passed to guest firmware, leaving the guest's DMI information empty. A command-line option existing on both architectures does not prove identical guest-visible behavior.
The repository includes 4 CI workflow files and a tests directory, but our 323-test run is only one environment. Build a matrix from the actual fleet: host architecture, kernel, guest OS, firmware, disk backend, network backend, passthrough devices, and sandbox mode. A generic statement that Cloud Hypervisor supports AArch64 is less useful than proving the chosen device and lifecycle operations on the server model you will deploy.
v53.0 is active infrastructure software
Release v53.0 arrived on July 12, 2026 with migration, snapshot, nested Hyper-V, clock, serial, VFIO, and validation work. GitHub records a push on August 26, 2026, 6,148 stars, and 203 open issues excluding pull requests. That issue count belongs to an active infrastructure project and includes feature tracking alongside defects; it is not a bug total.
Cloud Hypervisor has the scope and documentation to merit a serious proof of concept for modern cloud guests. Our run provides a clear stop sign rather than a dismissal: 295 tests passed, but 28 block I/O tests failed. Reproduce that suite on the target kernel, boot representative Linux and Windows images, test hotplug plus rollback, and keep migration inside one pinned release before putting tenant workloads on it.