Google propone VMs huérfanas: máquinas virtuales que sobreviven al reinicio del kernel

Google quiere que actualizar un host no obligue a apagar las máquinas virtuales que corren encima. Pasha Tatashin, ingeniero de la compañía, ha enviado a la lista del kernel una serie RFC de 46 parches que introduce el concepto de Orphaned VM: una máquina virtual que sigue ejecutando instrucciones de invitado sobre CPU físicas aisladas mientras el sistema operativo anfitrión y su VMM están completamente desconectados durante un reinicio. Los parches son experimentales, se han probado en procesadores Intel, AMD y Arm, y sus autores los describen como un trabajo en fase muy temprana, nada listo para producción.

Un vigilante entre el hipervisor y el arranque

La pieza central es el Caretaker, una capa de primitivas de bare metal que se ejecuta dentro del estado privilegiado del hardware del hipervisor y se encarga de atrapar y resolver localmente algunas salidas de VM mientras el kernel del host está apagado. La transición la orquesta el Live Update Orchestrator (LUO), también impulsado por Google y apoyado en kexec, que ya se usa para actualizaciones en vivo de kernel sin pasar por un arranque completo.

Lo difícil está en el hueco. Hay que preservar las estructuras vcpufd con el estado de las vCPU en RAM a través del reinicio, blindar las CPU físicas frente a las señales de reset que dispara el arranque y resolver lo que llega de forma asíncrona y sin nadie al mando: deriva del reloj, interrupciones sueltas y enrutado de IPI entre invitados. El conjunto incluye soporte para preservar núcleos de CPU física, un marco de planificación on-core y la infraestructura KVM Caretaker Core.

El interés es fácil de ver para quien opera nube a escala. Los hiperescaladores llevan años empujando hacia el mantenimiento sin caída de servicio, y hasta ahora un parche de seguridad del kernel del host o un reinicio por mantenimiento terminan arrastrando a los invitados. Tatashin plantea justo lo contrario: que la VM siga su ejecución en hardware aislado mientras el sistema que la aloja no existe.

Todo esto sigue en discusión. El envío es pidiendo comentarios al resto de implicados en el kernel, el trabajo se presentará en la Linux Plumbers Conference de Praga el mes que viene y la propia descripción de la sesión habla de explorar los mecanismos necesarios, no de una implementación cerrada. Aquí hay mucha superficie donde romperse: temporización, aislamiento, gestión de interrupciones y el modelo de seguridad de dejar invitados corriendo fuera del control del hipervisor.

Merece la pena seguirle la pista porque toca una de las costuras más incómodas de la virtualización: el host es un punto único de fallo para todo lo que corre dentro. Si algo de esta serie sobrevive al escrutinio de la lista y llega a mainline, cambia cómo se planifican las ventanas de mantenimiento en clústeres grandes. De momento es un RFC, y los RFC cambian o se caen.