Linux RFC Lets VMs Keep Running While the Host Kernel Reboots

A new experimental Linux KVM patch series is pushing host live updates toward an unusual goal: keep a virtual machine executing even while the host kernel that normally manages it is temporarily offline. The design calls these guests “Orphaned VMs” because their vCPUs continue running on preserved physical CPUs across the host’s kexec-based kernel replacement.

Phoronix reports that the current RFC spans 46 patches and has been tested in development environments across Intel, AMD and Arm server processors. The important status word is RFC: this is early upstream-facing engineering work, not a feature users can assume exists in a current distribution kernel or production hypervisor stack.

Normal KVM operation depends on the host kernel and a userspace virtual-machine monitor. The Orphaned VM architecture instead preserves the VM and vCPU state through Linux’s Live Update Orchestrator, isolates the physical CPUs assigned to the guest, and uses a small privileged “Caretaker” execution layer while the old host kernel is gone and the replacement kernel boots.

That Caretaker is not intended to reproduce an entire Linux host or VMM. The proposal describes it handling a constrained set of VM exits locally. If a guest triggers an exit that needs unavailable host-side handling, the affected vCPU can wait until KVM is attached again. This boundary is central to the design: continued guest instruction execution is possible only while the workload stays within what the preserved hardware state and Caretaker can service during the management gap.

Linux Live Update work already targets preserving resources across kexec so a VM can be recovered by the replacement kernel. The harder problem is the blackout interval: if the guest is paused while the host kernel, drivers and userspace come back, that maintenance still becomes visible as guest downtime or steal time.

The Orphaned VM work attacks that interval directly. Notes from the Hypervisor Live Update group describe a prototype workload continuing to make progress across kexec on Arm, Intel and AMD development environments. The same notes also show why the problem is not solved merely by keeping a CPU powered: emulated-device exits that require userspace MMIO handling are intentionally outside the initial architecture, and state such as timekeeping, interrupts and device ownership must survive the handoff coherently.

For cloud and virtualization operators, the long-term value is straightforward: host security updates and kernel replacements become much easier to schedule if guest compute can continue through most of the reboot rather than requiring migration or a visible pause. The architecture could be especially useful where moving large-memory VMs is expensive or where hosts need frequent kernel maintenance.

The engineering tradeoff is that the host is deliberately absent during the most unusual part of the transition. That makes the Caretaker’s supported exit set, CPU isolation, preserved memory and interrupt state, timekeeping, and reattachment semantics more important than a headline claim of “no reboot downtime.” The upcoming Linux Plumbers Conference 2026 session is positioned around those unresolved architectural details, which is appropriate for work still seeking upstream feedback.