Actualizar el kernel sigue siendo una de esas operaciones que obligan al administrador Linux a mirar dos veces el calendario de mantenimiento. El live patching permite corregir determinados fallos sin reiniciar, pero instalar un kernel realmente nuevo continúa suponiendo normalmente reiniciar el host, migrar máquinas virtuales o asumir una interrupción. Kexec HandOver (KHO) y Live Update Orchestrator (LUO) quieren cambiar precisamente esa parte del trabajo del sysadmin.
Las claves de KHO y LUO en 30 segundos
- KHO, incorporado inicialmente en Linux 6.16, permite conservar regiones de memoria durante un cambio de kernel mediante
kexec. - LUO amplía ese mecanismo para preservar y recuperar recursos utilizados por aplicaciones durante la transición.
- Google desarrolla
luo-agent, con el daemonluody la herramienta administrativaluoctl. - El objetivo más interesante está en hipervisores: cambiar el kernel del host sin tener que apagar las máquinas virtuales que ejecuta.
- systemd 261 ya incorpora soporte relacionado con LUO, aunque toda esta infraestructura sigue siendo joven y no debe confundirse con una actualización transparente disponible para cualquier servidor.
Para un administrador de sistemas la idea puede resumirse de una forma sencilla: el kernel antiguo desaparece y arranca uno nuevo, pero parte del estado necesario para las cargas de trabajo consigue cruzar de un lado al otro.
No es exactamente un servidor que nunca se reinicia. Tampoco es live patching. Hay un kexec y, por tanto, una sustitución efectiva del kernel. La diferencia está en intentar evitar que esa transición obligue a detener también todo lo que depende del host.
De kexec y KHO a un kernel completamente diferente
Linux dispone desde hace años de mecanismos para reducir el impacto de las actualizaciones del kernel.
Ksplice, kpatch y otras tecnologías de live patching pueden modificar determinadas partes de un kernel mientras continúa funcionando. Resultan especialmente útiles cuando aparece una vulnerabilidad que necesita corregirse rápidamente.
El esquema simplificado sería:
Kernel actual
|
+-- aplicar live patch
|
v
Mismo kernel + correcciónKHO y LUO persiguen algo distinto:
Kernel A
|
+-- preservar estado
|
+-- kexec
|
v
Kernel B
|
+-- recuperar estado
|
v
Continuar las cargas compatiblesLa pieza que hace posible el salto ya existía: kexec.
En lugar de apagar completamente el servidor, pasar por UEFI o BIOS, ejecutar el gestor de arranque y comenzar todo el proceso desde cero, kexec permite cargar otro kernel directamente desde el kernel que está funcionando.
El problema es que arrancar otro kernel significa perder el estado del anterior.
Ahí entra Kexec HandOver.
KHO apareció inicialmente en Linux 6.16 y proporciona infraestructura para conservar determinadas regiones de memoria durante una transición con kexec.
Para utilizarlo el kernel debe disponer del soporte correspondiente:
CONFIG_KEXEC_HANDOVER=yy KHO puede habilitarse mediante la línea de comandos del kernel:
kho=onTambién existe kho_scratch, que permite reservar memoria para el proceso. Una configuración de pruebas puede tener esta forma:
kho=on kho_scratch=16M,512M,256MLa documentación del kernel explica que KHO utiliza un Flattened Device Tree (FDT) para describir el estado que debe pasar al siguiente kernel. Las regiones preservadas permanecen disponibles durante el kexec, de manera que el kernel nuevo pueda localizarlas.
Esto soluciona una parte del problema: transportar memoria.
Pero conservar unos megabytes o gigabytes no basta para mantener funcionando una aplicación. El nuevo kernel necesita saber qué son esos datos y qué recursos debe reconstruir alrededor de ellos.
Ese es el trabajo que intenta organizar LUO.
LUO lleva la actualización en vivo al espacio de usuario
Live Update Orchestrator proporciona una infraestructura para coordinar recursos que deben sobrevivir a una transición de kernel.
El subsistema utiliza:
/dev/liveupdatecomo interfaz con el espacio de usuario.
Un orquestador crea sesiones LUO y las aplicaciones interesadas pueden asociar recursos a esas sesiones antes de ejecutar el cambio de kernel.
El flujo conceptual es:
Aplicación
|
+-- registra recursos
|
v
Sesión LUO
|
+-- preserve
|
Kernel A
|
+-- kexec
|
Kernel B
|
+-- retrieve
|
v
Aplicación restauradaLUO contempla operaciones relacionadas con la preservación, congelación, recuperación y finalización de los recursos.
Esto resulta especialmente interesante con elementos como memfd.
Un proceso puede disponer de una gran región de memoria asociada a un descriptor de fichero. En lugar de copiar todo su contenido a disco, destruirla y reconstruirla después del arranque, LUO puede ayudar a que esa memoria permanezca disponible durante la transición.
Es fácil imaginar por qué interesa a Google.
El escenario que importa al cloud: QEMU/KVM
Supóngase un nodo de virtualización Linux con varias decenas de máquinas virtuales QEMU/KVM.
Se publica una actualización importante del kernel.
El procedimiento habitual puede implicar algo parecido a esto:
1. Bloquear nuevas cargas en el nodo
2. Migrar las VM a otros hosts
3. Comprobar que el nodo está vacío
4. Actualizar el kernel
5. Reiniciar
6. Validar servicios y networking
7. Volver a incorporar el nodo al clústerEn un clúster pequeño es una tarea perfectamente manejable.
En una infraestructura con miles de hosts físicos la situación cambia.
Para poder evacuar nodos hacen falta capacidad disponible, red suficiente para las migraciones, automatización y bastante coordinación. Cuantas más actualizaciones urgentes haya que realizar, mayor es el coste operativo.
LUO intenta hacer viable otro modelo.
QEMU puede conservar recursos que necesita la máquina virtual, realizar la transición al nuevo kernel y volver a reclamar esos recursos después.
El objetivo sería aproximarse a:
HOST LINUX
+------------------+
| QEMU |
| |
| VM1 VM2 VM3 |
+---------+--------+
|
preservar estado
|
v
+------------------+
| Kernel A |
+------------------+
|
kexec
|
v
+------------------+
| Kernel B |
+------------------+
|
recuperar estado
|
v
+------------------+
| QEMU |
| VM1 VM2 VM3 |
+------------------+Eso no significa que cualquier VM pueda sobrevivir actualmente a cualquier actualización.
El estado de un hipervisor no está compuesto únicamente por RAM. También intervienen KVM, IOMMU, interrupciones y, dependiendo de la configuración, dispositivos asignados mediante VFIO, entre otros recursos.
Cada subsistema necesita saber cómo preservar y restaurar correctamente su parte del estado.
Precisamente por eso LUO se plantea como una infraestructura extensible y no como un simple comando live-kernel-upgrade.
Google publica luo-agent para administrar LUO
Además de las piezas incorporadas al kernel, Google mantiene públicamente luo-agent, un proyecto GPL-2.0 que proporciona componentes de espacio de usuario para controlar Live Update Orchestrator.
El proyecto se divide principalmente en dos herramientas:
luod
luoctlluod es el daemon encargado de controlar /dev/liveupdate, mantener las sesiones y coordinar los clientes.
luoctl proporciona la interfaz administrativa.
Una instalación desde el código fuente utiliza actualmente Meson y Ninja. En Debian o Ubuntu las dependencias indicadas por el proyecto pueden instalarse con:
sudo apt-get install meson ninja-build libjson-c-devLenguaje del código: JavaScript (javascript)Después:
meson setup build
ninja -C build
sudo ninja -C build installEl daemon puede administrarse como cualquier otro servicio de systemd:
sudo systemctl enable --now luodY aquí empieza la parte que resultará familiar para cualquier sysadmin.
El nuevo kernel puede cargarse previamente:
sudo luoctl load /boot/vmlinuz \
--initrd /boot/initrd.img \
--reuse-cmdlineLos clientes registrados pueden comprobarse mediante:
sudo luoctl listLenguaje del código: PHP (php)Y la transición termina lanzándose con:
sudo luoctl kexecNo debería interpretarse esa secuencia como una receta para probar directamente en un host de producción. El propio proyecto establece como requisito Linux 6.19 o posterior con CONFIG_LIVEUPDATE habilitado, además del soporte necesario en las cargas que se pretendan conservar.
El detalle interesante de luod: delegar en las aplicaciones
La arquitectura elegida para luo-agent tiene bastante sentido desde el punto de vista Unix.
luod actúa como propietario de /dev/liveupdate, pero no intenta conocer internamente cómo funciona cada aplicación.
Los clientes se conectan mediante un Unix Domain Socket:
/run/luod/liveupdate.socky pueden suscribirse utilizando un identificador.
Simplificando el protocolo:
SUBSCRIBE
|
v
PRESERVATION_REQUEST
|
v
START_PRESERVATION + Session FD
|
v
Cliente guarda sus recursos
|
v
READY
|
v
kexec
|
v
CLAIM
|
v
Recuperar Session FDLos descriptores se transfieren entre procesos mediante SCM_RIGHTS.
Esta arquitectura evita que luod necesite conocer todos los detalles internos de QEMU, una base de datos o un runtime de contenedores.
Cada cliente sabe qué necesita conservar.
El daemon coordina cuándo hacerlo.
systemd 261 entra también en la ecuación
Otro avance relevante para administradores Linux es el soporte introducido en systemd 261.
systemd dispone desde hace tiempo de un file descriptor store que permite a los servicios depositar descriptores para que el gestor los conserve.
Directivas como:
FileDescriptorStoreMax=y:
FileDescriptorStorePreserve=controlan este comportamiento.
Con LUO aparece la posibilidad de mantener esos descriptores incluso durante determinadas transiciones mediante kexec.
Eso abre escenarios interesantes más allá de las VM.
Piénsese en una caché que almacena decenas de gigabytes en memoria mediante memfd. Reiniciar el servicio y reconstruir completamente esa información puede tardar bastante.
Si el descriptor y la memoria asociada consiguen sobrevivir al cambio de kernel, el proceso posterior podría recuperar el recurso en lugar de reconstruirlo.
Algo parecido podría plantearse en el futuro para runtimes de contenedores, determinadas bases de datos o servicios de red.
Pero de nuevo conviene distinguir entre lo que permite diseñar la arquitectura y lo que ya está preparado para desplegarse de forma genérica.
¿Y qué ocurre con los sockets?
Aquí empieza una de las partes más interesantes del desarrollo futuro.
Mantener RAM es relativamente sencillo comparado con conservar todo el estado de un sistema Linux activo.
Una aplicación real puede depender de:
- memoria;
- archivos abiertos;
- sockets;
- pipes;
- dispositivos;
- interfaces de red;
- conexiones TCP;
- VFIO;
- IOMMU;
- estado interno de drivers.
Mantener un socket TCP abierto mientras desaparece un kernel y aparece otro requiere preservar bastante más información que el descriptor que lo representa.
Por eso LUO probablemente será más útil a medida que aumente el número de subsistemas capaces de serializar y recuperar su estado.
También aparece aquí CRIU (Checkpoint/Restore in Userspace).
CRIU permite congelar determinados procesos, almacenar su estado y restaurarlos posteriormente. Es una tecnología utilizada especialmente alrededor de contenedores y migración de procesos.
KHO, LUO y CRIU no son sustitutos directos.
Podrían terminar siendo piezas complementarias:
KHO
|
+-- conserva memoria entre kernels
LUO
|
+-- coordina recursos y aplicaciones
CRIU
|
+-- checkpoint/restore de procesosLa combinación resulta técnicamente atractiva porque permite atacar el problema desde diferentes capas.
Live patching y LUO probablemente convivirán
Para el administrador tampoco tendría sentido sustituir automáticamente kpatch o Ksplice por LUO.
Si una vulnerabilidad puede corregirse mediante un parche en vivo bien probado, aplicar ese parche puede ser la opción menos invasiva.
El problema aparece cuando se necesita instalar un kernel completo.
Los parches en vivo pueden acumularse y no todas las modificaciones del kernel son adecuadas para aplicarse mediante live patching.
LUO ofrece potencialmente una salida diferente: ejecutar finalmente el kernel nuevo sin tener que desalojar necesariamente todas las cargas del host.
En una infraestructura futura podrían convivir ambos mecanismos.
Aparece una vulnerabilidad crítica y se aplica inicialmente un live patch. Posteriormente el administrador despliega el kernel corregido mediante LUO durante una ventana de mantenimiento mucho menos intrusiva.
¿Está listo para probarse en Ubuntu?
Probar la tecnología y utilizarla en producción son dos decisiones completamente diferentes.
KHO y LUO ya tienen piezas dentro del kernel principal y systemd está incorporando soporte, pero la infraestructura continúa evolucionando.
Una línea de arranque para un entorno preparado específicamente para experimentar podría incluir:
GRUB_CMDLINE_LINUX="kho=on kho_scratch=16M,512M,256M liveupdate=on"Lenguaje del código: JavaScript (javascript)Después habría que actualizar GRUB según la distribución y reiniciar inicialmente el sistema para activar esos parámetros.
Pero habilitar las opciones no proporciona por arte de magia actualizaciones transparentes.
Hay que comprobar:
uname -rla configuración del kernel:
grep -E 'CONFIG_KEXEC_HANDOVER|CONFIG_LIVEUPDATE' \
/boot/config-$(uname -r)Lenguaje del código: JavaScript (javascript)y la disponibilidad de la interfaz:
ls -l /dev/liveupdateAdemás hay que trabajar con aplicaciones expresamente preparadas para participar en el procedimiento.
Por eso hoy LUO resulta especialmente interesante para laboratorios, desarrolladores del kernel, fabricantes de distribuciones, proveedores cloud y equipos que operan grandes plataformas de virtualización.
No es todavía el sustituto del clásico:
sudo rebooten un servidor cualquiera.
El verdadero cambio para el administrador Linux
El atractivo de LUO no está en poder decir que Linux «ya no necesita reiniciarse».
Linux seguirá necesitando reinicios por muchos motivos. Actualizaciones de firmware, cambios de hardware, determinados drivers o problemas físicos no desaparecen porque exista kexec.
La idea importante es otra.
Durante décadas el administrador ha tratado como prácticamente inseparables estas dos operaciones:
cambiar el kernel
=
interrumpir las cargas del hostKHO y LUO intentan romper esa dependencia.
Para un portátil la diferencia puede ser poco relevante. Reiniciar durante 30 segundos no supone ningún drama.
Para un hipervisor con 80 máquinas virtuales es otra historia.
Y para un proveedor con decenas de miles de servidores físicos, actualizar el kernel sin tener que migrar previamente todas las VM puede modificar por completo el coste operativo de mantener la plataforma parcheada.
Por eso merece la pena seguir KHO y LUO aunque todavía no formen parte del arsenal cotidiano del sysadmin.
El día realmente interesante llegará cuando un administrador pueda comprobar el kernel disponible, cargarlo, realizar una transición controlada y descubrir que las máquinas virtuales, caches o servicios que estaban funcionando antes siguen ahí después del cambio.
Ese sería un cambio bastante más profundo que conseguir que reboot tarde unos segundos menos.
Preguntas frecuentes
¿LUO permite actualizar Linux sin reiniciar?
LUO sigue realizando una transición de kernel mediante kexec. La diferencia es que intenta preservar recursos y cargas durante el cambio, evitando un reinicio convencional completo y reduciendo la interrupción de los servicios compatibles.
¿Qué diferencia hay entre KHO y LUO?
KHO proporciona el mecanismo de bajo nivel para preservar memoria durante un kexec. LUO añade una infraestructura para que el espacio de usuario y distintos subsistemas registren, preserven y recuperen los recursos necesarios.
¿Puede utilizarse ya LUO en servidores de producción?
La tecnología ya tiene componentes en el kernel principal, pero continúa evolucionando y necesita soporte específico de los recursos y aplicaciones que se quieran conservar. Conviene tratarla todavía como una tecnología para pruebas y despliegues muy controlados.
¿LUO sustituirá a Ksplice, kpatch o tecnologías similares?
No necesariamente. El live patching modifica un kernel que continúa funcionando, mientras que LUO pretende permitir la transición hacia otro kernel. Ambos enfoques pueden ser complementarios.
Fuentes:
- Linux Kernel Documentation, Kexec HandOver (KHO).
- Linux Kernel Documentation, Live Update Orchestrator.
- Google Production Kernel,
luo-agent, GitHub. - systemd 261, soporte de Live Update y File Descriptor Store.
- Documentación de CRIU, Checkpoint/Restore in Userspace.
