Releases · Cloud Hypervisor

Cloud Hypervisor v54.0 guarantees live migrations from the last two releases

The Rust VMM's first live-migration compatibility guarantee accepts arrivals from v52.0 and v53.0, and the release adds VFIO device migration and migration cancellation, changes two defaults, tightens upgrade checks, and fixes silent data corruption after live migration.

By BoneFriday 16 October 20263 min readReleases

entryread only

filedFriday 16 October 2026

length3 min

sectionReleases

subjectCloud Hypervisor

sourceson the page

Cloud Hypervisor v54.0, released on 14 October, is the first version of the Rust virtual machine monitor with a live-migration compatibility guarantee, and that is the headline for VM fleet operators. The project runs on top of KVM and the Microsoft Hypervisor (MSHV), and shares code and architecture with Firecracker and crosvm. It also flips two defaults, drops disk image autodetection, and carries one fix that matters more than any feature.

The n-2 guarantee

Starting with this release, Cloud Hypervisor guarantees that live migrations from the two previous releases are accepted (“n-2”): v54.0 accepts migrations from v52.0 and v53.0. Longer jumps might work, but the project strongly recommends incremental upgrades, for example from v54.0 to v56.0 to v58.0. Going back is not a promise: “Migrating back to an older release is not officially supported.” The protocol version is now an internal detail, and new VMM functionality falls back to safe values for VMs from older versions, so only newly spawned VMs can use it.

VFIO migration and cancellation

VMs with migratable VFIO devices, for example ConnectX VFs bound to mlx5_vfio_pci, can now be live migrated: device state travels with the guest and device-written memory is tracked during the move. It needs --platform iommufd=on and a migration-capable host driver; devices behind a virtual IOMMU cannot be migrated yet. An ongoing migration can also be cancelled with the new vm.cancel-migration API endpoint or the ch-remote cancel-migration command. The VM keeps running on the source, a vm.migration-cancelled event is emitted, and after a failed or cancelled migration the VMM attempts to restore the source to its pre-migration state.

What the upgrade changes

Nested virtualization is now disabled by default on all architectures (“It widens the attack surface of the host kernel, and most users do not need it”), so guests that virtualize need --cpus nested=on. The virtio-net offloads (offload_csum, offload_tso, offload_ufo) are off by default too, because they make the host do more work for the guest’s packets. Both defaults apply to the command line and the API, and VMs restored from a snapshot or received through live migration keep their configured values. The removals: disk image autodetection is gone, so image_type is required on every disk that is not a vhost-user disk; the memory_mode option of receive-migration is removed; and unaligned requests to raw and fixed VHD disks with direct=on now fail with an I/O error instead of read-modify-write emulation. One more caution: new CPUID compatibility checks (leaf 0x7 sub-leaves, AMX and XSAVE state components) “may reject migrations to hosts that previously appeared to work.”

The fix and the numbers

The most consequential item sits in the bug-fix list: silent data corruption after live migration, where disk reads and received network frames written into guest memory during pre-copy could arrive with stale content on the destination (#9015). The numbers, as stated by the release notes: prefaulting a 3 TiB guest on a two-socket host drops from 51.8 s to 7.4 s, vCPU save and restore are up to 5-9 times faster, and serialized state for a 16-disk VM is about 29% smaller.

My read

The n-2 guarantee is the structural change: accepting migrations from two releases back turns rolling upgrades from a test campaign into a routine. Everything else asks for one rehearsal before production. The defaults and the removals need a config pass, the CPUID checks can reject hosts that used to work, and the corruption fix is reason enough to move for anyone who migrates VMs already.

Source: the v54.0 release notes and the live migration documentation.

ReleasesHomebridge 2.5.0 is a Matter release: new device types, and fixes for identity and cacheHomebridge 2.5.0 adds Matter device types for solar, battery, EV chargers, meters, tariffs and water heaters, and spends the rest of its list on behaviour that used to go wrong: air quality reporting only two levels, thermostats registering late, restored accessories losing their uniqueId or owner, and cache reads that took the accessory with them. It also bumps @matter/main to v0.18.0 and @homebridge/hap-nodejs to v2.3.0.

ReleasesMealie 3.30.0 lets you own the AI prompt, time each step, and plan a whole weekMealie 3.30.0 moves AI prompt control into the app, so prompts can be appended to, replaced or extended with global instructions, and it retires the OPENAI_CUSTOM_PROMPT_DIR variable while importing existing prompts automatically. Instruction steps gain individual durations, meal plan entries can cover a full week, and a batch of fixes tightens import scoping, locale lookup and the permissions needed to manage units, tools, labels and recipe actions.

ReleasesMemos 26.10.0 signs API clients out, stops reading /etc/secrets and makes export an admin jobMemos 26.10.0 is the first release under calendar versioning, and its upgrade notes matter more than its features: old installs need a 0.31.0 waypoint, cached access tokens expire on upgrade, the /etc/secrets files from 0.31.0 are no longer read, member export disappears, and the old upload and memo-length settings are replaced without migration. The features are a rich editor by default, per-user usage limits and declarative configuration.