Should you build on Cloud Hypervisor?
Choose a proof of concept if you need a VMM for modern cloud guests and can own the surrounding infrastructure. Cloud Hypervisor supports 64-bit Linux and Windows guests, with virtio-oriented I/O and limited legacy emulation. Its documented hotplug support includes CPUs, memory resizing, VFIO devices and several virtio devices. Those capabilities make it relevant to cloud platform engineering; they do not make the binary a complete deployment system.
Cloud Hypervisor is a Rust virtual machine monitor that runs on KVM or Microsoft Hypervisor (MSHV). The project README identifies x86-64 and AArch64 as its main architectures, with different functionality across them. RISC-V support is experimental and limited. Select your host architecture and required devices before treating the feature list as an acceptance checklist.
What our sandbox established
Our run on October 10, 2026, at commit 51126e8 built successfully, but the test command failed; it does not establish that a guest deployment worked.
The matching stored record identifies the full commit as 51126e84683e898dd54844e6b77f602bae16003c. Our sandbox used lab-rust:1, 3 CPUs and 12 GB of memory. The harness recorded each command's success flag, exit code, elapsed time and timeout status, alongside output tails and parsed test summaries. Install returned zero after 21 seconds, build returned zero after 95 seconds, and cargo test returned 101 after 358 seconds without timing out.
The attached stored parser summaries contain 702 passed, 56 failed and 758 total. The record warns that identical Cargo summaries appear before and after a replay marker. These stored aggregates may double-count suites; they are not verified unique or exhaustive test counts, and we do not calculate a pass rate from them.
Separately, the raw block-library tail names failures in QCOW, raw, VHD and asynchronous io_uring paths. Examples include formats::raw::tests::try_clone_preserves_io_uring_backend and io_impl::async_io::uring_data_io::tests::uring_drop_drains_in_flight_operations. Visible panics report PermissionDenied with "Operation not permitted". That establishes a permission error at those observed failure points, but does not identify which host or sandbox restriction caused it or prove that every named failure has the same cause. Cargo points to -p block --lib for a targeted rerun.
The record does not establish a guest boot, workload execution, hotplug operation, snapshot restore or migration between hosts. It also contains no audit result or scanned-package coverage, so it supports no security assessment. The testing-methodology page explains the publisher's command recording and general limits. Its currently published procedure is context, not proof that every current setting applied to this older run.
Check the host requirements for your revision
The README at the measured commit recommended host kernel 5.13 and said most CI used 5.15. The current README specifies a minimum supported host kernel of 6.8. Use the documentation for the revision you intend to deploy; neither statement identifies our sandbox's actual kernel.
The recommended entry point is a prebuilt binary. Guests can boot through firmware or a suitable kernel, but you must still supply the guest disk and configure networking. AArch64 hosts require a GICv3 interrupt controller. The README's tap-networking example grants cap_net_admin, which is another host configuration step to account for when reproducing a guest boot.
Keep migration inside a coordinated release
Snapshot restore and live migration are not supported across different Cloud Hypervisor versions.
That boundary appears in both the measured-commit README and the current README. The API stability policy separately promises at least two major releases of notice before breaking changes. API notice does not establish cross-version VM-state compatibility.
The v53.0 release notes describe an external snapshot/restore daemon, postcopy migration and mutual TLS for migration data. These are documented release features, not operations demonstrated by our run. Before relying on them, rehearse restore and host evacuation with your selected VMM revision, firmware, guest images and devices.
Treat historical issue reports as version-specific evidence
Issue 8796 reported missing vhost-user block resize notifications with Cloud Hypervisor 54.0.0-rc4. The supplied issue page shows it was closed as completed through pull request 8824 on September 1, 2026. It therefore does not support presenting that report as an unresolved limitation of every current checkout.
If online disk resizing matters to your fleet, verify it on the exact revision and backend you select. The issue's closure is useful maintenance evidence, but it does not show that our sandbox exercised the fix.
Which alternatives answer a different need?
Firecracker targets container and function services using lightweight microVMs. Its README makes that purpose explicit. Evaluate it as a VMM alternative when that workload model matches your service; this evidence does not establish a performance advantage over Cloud Hypervisor.
crosvm documents graphics, display and audio devices for guest workloads. Its README describes virtio-gpu acceleration, Wayland passthrough and virtio-snd backends. Evaluate it when those guest interactions matter. Both projects are VMM choices; neither comparison here is a measured head-to-head result.
How to read the editorial scores
These are editorial assessments, not benchmark results. The rubric is: 1 means substantial documented obstacles or little supporting material; 2 means substantial manual integration remains; 3 means a documented route with material gaps; 4 means broad documented capabilities with explicit operational limits; 5 means the assessed documentation or participation routes cover the evaluation needs described here. A score does not measure adoption, security or production reliability.
Setup ease is 2 because a successful source build leaves host virtualization, boot artifacts and networking to the operator. Documentation is 5 for its coverage of boot paths, architectures, hotplug and compatibility limits, although readers must match it to their revision. Community is 5 only for documented participation routes, including contributions, issue reporting, Slack and a mailing list; response speed and adoption remain unassessed. Maturity is 4 for the documented lifecycle features, stability policy and release fixes, qualified by unsupported cross-version VM-state compatibility and our failed test command.
The next useful step is to reproduce the named io_uring failures on the intended host, then boot a representative guest and test the lifecycle operations your fleet needs. A successful compile alone cannot settle that deployment decision.