A host kernel update stops virtual machines. The kernel is replaced, the VMM restarts, the guests are parked and re-attached. A 46-patch RFC posted on 20 September keeps them running instead.
What it does
Pasha Tatashin, at Google, builds on the Live Update Orchestrator, upstream since 6.19 and itself built on Kexec Handover. Preserved guests used to be orphaned during the window between the outgoing kernel and its userspace VMM going away and the incoming stack booting up, and the usual answer was to park their vCPUs until it was over.
Orphaned VMs keep the guest executing on physical CPUs that are shielded from the reboot, under a small on-core runtime he calls the KVM Caretaker. The Caretaker runs in the hypervisor’s privileged hardware state and traps VM exits itself, resolving what it can with no host kernel and no VMM underneath: timers, basic MSRs, a limited amount of I/O. It only activates when a live-update session preserved both the vCPU and the physical CPU it was running on, and otherwise falls back to keeping vCPU state in memory. vCPU file-descriptor state crosses the gap, the reserved cores are protected from boot-time reset signals, and the awkward parts of running with no host to ask, timekeeping drift, stray interrupts and guest-to-guest interrupts, are handled explicitly. Optional telemetry records the exits and stalls that happened during the blackout so the incoming kernel can read them afterwards.
It has been exercised on Intel Granite Rapids, AMD EPYC Turin and Arm Neoverse V2, plus QEMU and Simics.
What it is not
Not a merge candidate. Tatashin calls it an end-to-end demo for the KVM microconference at Plumbers in October, very early work and nowhere near production ready. The series is split into preparation, CPU preservation, on-core execution, the Caretaker core and the x86 and arm64 backends, and the point of posting it is design review of that layering rather than a run at mainline.
My read
This is the maintenance story the cloud wants, where a security update costs a guest a fraction of a second instead of a reboot, and for a homelab it would mean patching the kernel under a running virtual machine with no maintenance window. It is not something to plan around yet. The part worth watching is the trust problem rather than the plumbing: for that gap the guest is executing on hardware whose kernel cannot intervene if anything goes wrong.
Source: RFC PATCH 00/46, Orphaned VMs, with the session listed as In-Kernel Caretaker for Orphaned VMs at the LPC’26 KVM microconference