Linux has allowed applying certain security patches to the kernel without shutting down a machine for years, but replacing the entire kernel with a different version while keeping workloads like virtual machines, databases, or in-memory services alive is a much more complex challenge. Two technologies developed largely around Google’s needs—Kexec HandOver (KHO) and Live Update Orchestrator (LUO)—are bringing this possibility closer to standard kernels and could change the way high-availability Linux infrastructure is maintained.
Highlights of KHO and LUO in 20 seconds
- KHO arrived in Linux kernel 6.16 and allows preserving memory regions during a transition via
kexec. - LUO was later incorporated in Linux 6.19 and manages the preservation and recovery of resources between both kernels.
- Its primary use case is in cloud hypervisors where rebooting the host would disrupt virtual machines.
- systemd 261 already integrates LUO to preserve service file descriptors.
- It remains a technology under development: changing kernels without traditional rebooting doesn’t yet mean any server can update seamlessly.
This distinction is important because LUO isn’t simply another live patching system. Ksplice, kpatch, or KernelCare allow modifying running kernel code, which is very useful for fixing specific vulnerabilities without rebooting, but the kernel remains essentially the same.
KHO and LUO propose a different operation: genuinely booting another kernel via kexec while attempting to transfer some of the workload’s state to it.
Kernel documentation describes Live Update as a specialized reboot process based on kexec capable of moving from one kernel version to another while preserving certain resources and keeping compatible devices operational during the transition. The driving use case has been Linux as a hypervisor in large cloud environments.
KHO: the memory bridge between two kernels
kexec isn’t a new technology. Linux has supported loading a new kernel from the running kernel for years, bypassing part of the normal boot process and avoiding going through the machine’s firmware again.
The challenge lies in the state.
A new kernel typically starts from a clean slate. Memory and certain resources belonging to the previous kernel can’t just be considered valid for the new one.
Kexec HandOver (KHO) introduces infrastructure to preserve specific memory regions during this transition.
KHO was integrated into Linux 6.16 in 2025. The kernel documentation defines it as a mechanism capable of preserving memory regions—possibly containing serialized system state—across kexec execution.
Its operation revolves around a structure called Flattened Device Tree (FDT). The old kernel describes which regions to preserve, and this info is carried over to the transition. The new kernel can then retrieve these blocks and reconstruct the corresponding state.
Simply put, the process looks like this:
Linux Kernel A
│
├── Discardable state
│
└── Memory to be preserved
│
▼
KHO
│
kexec
│
▼
Linux Kernel B
│
└── Restores preserved regionsThe current documentation states that the kernel must be compiled with:
CONFIG_KEXEC_HANDOVER=yand enabled at boot time with:
kho=onIt is also possible to reserve auxiliary memory zones via kho_scratch. An example provided by the kernel documentation is:
kho_scratch=16M,512M,256Mwhich reserves specific areas remaining available for required operations during future kexecs.
Subsequently, the new kernel is loaded using the kernel’s own kexec_file loader:
kexec -l /path/to/bzImage --initrd /path/to/initrd -sand the transition is executed with:
kexec -eThe -s option is noteworthy: the documentation indicates that user-space tools currently lack equivalent LUO support with the traditional loader.
But KHO alone doesn’t solve the entire problem.
It can provide memory to the next kernel. The missing piece is understanding what that memory represents, which processes use it, and how to reconstruct resources depending on it.
That’s where LUO comes in.
LUO: keeping workloads alive during kernel changes
Live Update Orchestrator was integrated into the mainline kernel in Linux 6.19, built on the foundation provided by KHO.
Its purpose is to coordinate the entire preservation process.
LUO manages sessions that group resources needing to survive the transition. A user-space agent creates a session, incorporates resources to be preserved, and when kexec is invoked, the kernel serializes the necessary information.
After the new kernel boots, the same session can be recovered by name.
The basic cycle is:
1. Create LUO session
2. Register resources
3. Preserve state
4. Freeze necessary elements
5. Execute kexec
6. Boot new kernel
7. Recover session
8. Rebuild resources
9. Resume workloadThe interface is usually located at:
/dev/liveupdateand is controlled via ioctl calls. Only one process can hold /dev/liveupdate open at a time to prevent multiple orchestrators from trying to perform updates simultaneously.
To enable LUO, the kernel must boot with:
liveupdate=onCurrent documentation explicitly mentions subsystems like KVM, IOMMU, interrupts, VFIO, memory, and certain filesystem types as potential participants in the process.
This helps explain Google’s strong interest in the project.
The challenging case: updating the host without shutting down its VMs
Consider a physical server running dozens of virtual machines.
A kernel vulnerability arises requiring an update to a new version.
The traditional approach would be to migrate VMs elsewhere or shut down the server, apply updates, and reboot.
In large clouds, these operations are costly.
- They cause visible downtime
- Require additional capacity for migration
- Increase network traffic
- Extend operational time windows
- Demand coordination across thousands of hosts
LUO envisions a different scenario.
A VM managed via QEMU/KVM stores much of its state in memory and uses kernel resources such as memfd, VFIO, or IOMMU.
If those elements can be preserved during kexec, the host could:
Old kernel
│
├── QEMU
│ └── Running VM
│
▼
Preserve memory and resources
│
▼
kexec
│
▼
New kernel
│
├── Recover resources
└── Reassociate them with the VMLUO documentation explicitly states that the goal is for VM workloads using vfio, memfd, or iommufd to retain their essential resources during the transition. Some devices may even continue DMA activity while the kernel changes.
From a VM user’s perspective, this means the hypervisor kernel update should have minimal or no perceivable disruption.
That’s quite different from applying a patch to a few functions.
In essence, the server ends up running another kernel.
Google also published luo-agent to oversee the process
While the kernel provides the infrastructure, someone needs to coordinate it from user space.
Google maintains the open project googleprodkernel/luo-agent, mainly written in C and licensed under GPL-2.0.
The project has two main components:
luodis the daemon managing /dev/liveupdate.
And:
luoctlis the administrative tool used to load kernels, manage sessions, and initiate transitions with kexec.
The architecture aims to prevent each application from directly controlling the entire process.
luod maintains sessions, while clients like QEMU processes subscribe via Unix socket connections.
The typical flow is roughly:
Administrator
│
luoctl
│
▼
luod
│
├── QEMU client
├── Database
└── Other compatible service
│
▼
LUO sessions
│
▼
KernelAccording to the project documentation, clients connect to:
/run/luod/liveupdate.sockand can receive session descriptors via SCM_RIGHTS, the Unix mechanism for transferring file descriptors between processes.
Before the switch, clients receive a preservation request, save resources, and respond when ready.
After kexec, they reconnect using the same identifier and claim their session again.
This approach is particularly interesting because it avoids enforcing a single state format for all applications. Each client can better manage its resource needs than a central orchestrator.
Systemd 261 now supports file descriptor preservation during updates
LUO isn’t limited to Google’s experimental agent anymore.
The current kernel documentation explicitly states that systemd, since version 261, integrates LUO support and can preserve file descriptors per service during kernel updates based on kexec.
Services can specify options like:
FileDescriptorStoreMax=and:
FileDescriptorStorePreserve=to indicate which descriptors to retain.
This is significant because file descriptors are more than just numbers.
- Open files
- Pipes
- Specific sockets
- Memory via
memfd - Resources provided by devices
- LUO sessions
Preserving them allows a new service after transition to access resources belonging to the previous process.
For example, consider a memory cache application like memcached: its gigabytes of data could reside in a memfd, be preserved during change, and accessed without rebuilding the cache from storage.
This greatly broadens LUO’s relevance beyond hypervisors.
Databases, containers, and networking could be next
The documentation explicitly states the design aims to be workload-independent.
It specifically mentions:
- virtual machines
- containers
- high-performance databases
- network services
- in-memory caches
However, there’s an important difference between the framework supporting them and any current application automatically surviving a kernel change.
LUO requires drivers capable of preserving various resource types.
Therefore, its architecture includes operations like:
can_preserve()
preserve()
freeze()
retrieve()
finish()The old kernel needs to serialize state, and the new kernel must know how to reconstruct it.
This is an extensible infrastructure, not a universal time machine for any Linux process.
In that sense, it can complement another known technology: CRIU (Checkpoint/Restore In Userspace).
CRIU allows capturing process states and restoring them later. It’s used for container migration, checkpointing, and more.
KHO, LUO, and CRIU operate on different layers, but together they enable scenarios where part of the state remains in RAM while another is serialized and reconstructed from user space.
Much work remains before such a system becomes transparent to any application.
It’s not exactly a «zero-reboot» upgrade
It’s important to clarify this point.
Claiming LUO allows changing the kernel «without rebooting» can be a helpful summary but may be technically misleading.
There is a kernel restart.
The old kernel stops executing and a new one starts up.
What is being eliminated is the traditional full machine reboot and, especially, the interruption of the workloads depending on it.
The full cycle like:
power off
BIOS/UEFI
firmware
bootloader
kernel
services
applicationsis replaced by:
old kernel
│
kexec
│
new kerneland KHO/LUO aim to carry sufficient state between these two.
This distinction is key because it also defines the technology’s limits.
Changes in firmware, certain hardware modifications, or issues requiring physical device resets will still need other forms of maintenance.
LUO does not replace live patching
Technologies like Kpatch, Ksplice, and similar continue to make sense.
They serve different needs than LUO.
Live patching would be:
Kernel 6.x
│
Apply patch
│
Kernel 6.x modifiedLUO, on the other hand, proposes:
Kernel A
│
preserve state
│
kexec
│
Kernel BFor a small vulnerability, patching a few functions may be less risky than replacing the entire kernel.
But live patching has limitations.
Not every change can be turned into a live patch, and over time, discrepancies can accumulate between the original kernel and its patched version.
A full transition enables running the kernel with all fixes applied.
That’s why both approaches may coexist: live patching for rapid fixes and LUO for comprehensive updates with minimal downtime.
Caution: not for instant deployment in production
Although the technology is now part of the mainline kernel, it remains immature.
Official documentation for the Live Update API explicitly warns that it’s still under development and compatibility cannot yet be guaranteed across different kernel versions. Stability is expected in a later phase.
KHO also maintains debug interfaces that the documentation warns could change as the subsystem stabilizes.
Therefore, finding CONFIG_KEXEC_HANDOVER or LUO support in a distribution does not automatically make this mechanism ready for critical servers.
For example, the current luo-agent repository requires a Linux 6.19 or newer kernel with CONFIG_LIVEUPDATE enabled.
A test setup might include:
kho=on
kho_scratch=16M,512M,256M
liveupdate=onbut that only enables kernel features. The workloads themselves must also support resource preservation.
Why this technology matters more today than ten years ago
Kernel reboot issues are not new.
What has changed is the scale of the infrastructure relying on Linux.
A cloud provider might have thousands of physical hypervisors. A single host can run dozens or hundreds of VMs.
When a serious vulnerability emerges, updating isn’t just scheduling a nightly reboot.
- VMs must be evacuated or migrated
- The host must be updated and rebooted
- Additional capacity is needed for migration traffic
- Coordination across many hosts is required
- Operational errors could cause outages
In data centers with GPUs, the operations are even more complex due to resource costs and device passthrough or VFIO configurations.
Furthermore, automated vulnerability discovery accelerates the identification of new software flaws. AI tools are contributing, but the current kernel vulnerability volume cannot be attributed solely to them.
Reducing operational costs for quick kernel updates lessens the incentive to delay patches.
That’s likely where the real significance of KHO and LUO resides.
They’re not about claiming Linux never needs rebooting.
Rather, it’s about separating two traditionally linked tasks:
updating the host OS and stopping the running workloads.
If this separation proves stable with VMs, devices, containers, networks, and databases, a kernel update could become much more like routine maintenance.
That day has not yet arrived.
But since Linux 6.16 with KHO, Linux 6.19 with LUO, and systemd 261 with file descriptor support, the core components are no longer just experimental. They’ve become part of the standard Linux infrastructure.
Frequently Asked Questions
Can Linux now update any kernel without rebooting the server?
Not transparently for all systems. While KHO and LUO enable transitions via kexec that preserve certain states and resources, they require kernel, user space, and application support.
How is LUO different from Kpatch or Ksplice?
Kpatch and Ksplice perform hot patches—modifying the running kernel without rebooting. LUO facilitates booting a different kernel via kexec while attempting to preserve workload resources.
Which Linux versions include KHO and LUO?
Kexec HandOver was introduced in Linux 6.16. Live Update Orchestrator appeared in Linux 6.19. Support was integrated into systemd starting with version 261.
What is Google’s luo-agent used for?
luo-agent provides user-space components coordinating LUO. It includes the luod daemon and luoctl tool for loading kernels, managing sessions, and initiating kexec transitions.
Sources:
- Linux Kernel Documentation, Kexec HandOver (KHO).
- Linux Kernel Documentation, Live Update Orchestrator and Live Update uAPI.
- Google Production Kernel, open project
luo-agenton GitHub. - systemd 261, file descriptor store integration with LUO.
- Phoronix coverage of KHO in Linux 6.16 and LUO in Linux 6.19.
