Live Patch en vSphere 9 es una de las novedades más interesantes de esta versión de VMware. Sobre el papel promete parchear hosts sin evacuar máquinas virtuales, y eso suena muy bien, pero conviene entender bien qué significa realmente. VMware amplió esta capacidad en el contexto de vSphere con VMware Cloud Foundation 9.0, extendiéndola a más partes del host que en la primera iteración vista en vSphere 8 Update 3.
Porque una cosa es lo que parece cuando lo lees rápido, y otra lo que pasa de verdad cuando te pones a mirar qué componentes entran en Live Patch, cuándo aparece Fast-Suspend-Resume y qué impacto puede haber aunque no apagues las VMs. VMware habla ya de cobertura sobre vmkernel, daemons en user space, componentes NSX y también el entorno vmx de las máquinas virtuales.
Y aquí es donde me parecía interesante pararme un poco, porque Live Patch en vSphere 9 tiene muy buena pinta, pero no conviene venderlo como si fuera magia. Reduce mucho la necesidad de evacuar hosts, sí, pero sigue teniendo límites, compatibilidades y matices que merece la pena conocer antes de darlo por hecho en producción. Esa es, para mí, la parte importante.
Qué permite realmente Live Patch en vSphere 9
Live Patch apareció inicialmente con vSphere 8 Update 3, con la idea de aplicar determinados parches sin migrar cargas ni meter los hosts en un maintenance mode completo. En vSphere/VCF 9.0 esa superficie crece bastante, y por eso ahora tiene más sentido prestarle atención que en su primera versión.
Lo importante aquí no es solo que exista la funcionalidad, sino que ahora cubre más partes del host. VMware explica que Live Patch en vSphere/VCF 9.0 puede abarcar vmkernel, user-space daemons, NSX y vmx, lo que aumenta las posibilidades de que un parche pueda aprovechar este mecanismo. Además, NSX pasa a formar parte de la imagen base de ESX en este modelo, así que también entra en ese flujo de parcheo sin tener que evacuar previamente las VMs del host.
Eso sí, no todos los parches valen. Aquí conviene quedarse con una idea muy simple: que el entorno sea nuevo no significa que cualquier parche vaya por Live Patch. Hay que revisar las release notes del parche y también la información que muestra vSphere Lifecycle Manager, porque es ahí donde VMware indica si ese parche concreto es compatible con este método.
Requisitos para usar Live Patch en vSphere 9
Aquí hay un punto importante, porque si esta base no está bien, el resto da un poco igual.
VMware liga Live Patch a clústeres gestionados por vSphere Lifecycle Manager usando una sola imagen. La documentación oficial indica además que la opción está desactivada por defecto y que está pensada para aplicar parches de seguridad y correcciones urgentes en clústeres gestionados con imágenes.
También hay que tener en cuenta el punto de partida del entorno. VMware indicó para vSphere 9.0 que el upgrade directo de vCenter solo está soportado desde vSphere 8.0, no desde 7.0, y que vCenter 9.0 ya no gestiona hosts ESX 7.0 o anteriores. Además, los clústeres y hosts gestionados por baselines ya no son compatibles en vSphere 9: hay que pasar sí o sí a image-based lifecycle management.
Dicho de forma más clara: si alguien sigue con una mezcla heredada de versiones antiguas y baselines, primero toca ordenar el lifecycle. Luego ya hablamos de Live Patch.
Arquitectura o escenario típico
Para verlo más claro, yo lo bajaría a un escenario sencillo de laboratorio o de una producción pequeña:
vCenter 9
└── Cluster ESX 9 gestionado con imagen
├── Host 1
├── Host 2
└── Host 3
└── Máquinas virtuales en ejecución
Si el parche es compatible con Live Patch, vSphere Lifecycle Manager puede remediar ese clúster sin obligarte a evacuar previamente las VMs de cada host. Eso no significa que no pase nada durante el proceso. Significa que el parcheo evita el workflow clásico de maintenance mode con evacuación completa, que es justo donde está la mejora.
Qué impacto tiene Live Patch en vSphere 9 sobre las VMs
Esta es la parte donde conviene no autoengañarse.
VMware deja claro que durante un Live Patch algunos servicios del host pueden reiniciarse. Por ejemplo, si el parche afecta a hostd, el host puede aparecer brevemente desconectado en vCenter. Ese comportamiento está contemplado y, según VMware, no afecta al funcionamiento de las máquinas virtuales que siguen ejecutándose en ese host.
Ahora bien, eso no quiere decir que el proceso sea invisible en todos los casos. Si el parche toca vmx, las VMs hacen Fast-Suspend-Resume. VMware lo presenta como una operación no disruptiva, pero existe. No es exactamente lo mismo que decir que no pasa absolutamente nada. Pasa algo, solo que ese algo está diseñado para no convertirse en una caída clásica del servicio.
Y este matiz, en mi opinión, es importante. Porque Live Patch está muy bien, pero conviene explicarlo bien: reduce muchísimo la fricción operativa, sí, pero no significa barra libre ni impacto cero en todos los escenarios.
Qué es Fast-Suspend-Resume y cuándo entra en juego
Fast-Suspend-Resume, o FSR, es seguramente la parte que más dudas va a generar.
VMware explica que FSR es una operación no disruptiva que ya se usa en algunos cambios sobre máquinas virtuales encendidas. La comparación más útil es pensar en algo parecido a una especie de migración local dentro del mismo host. La memoria se mantiene en el propio host y no se produce una vMotion hacia otro nodo. Eso es lo que permite que, cuando Live Patch toca vmx, la VM consuma el nuevo entorno de ejecución sin necesidad de evacuar previamente el host.
Además, VMware destacó para vSphere/VCF 9.0 una mejora importante del FSR en máquinas virtuales con vGPU. En su ejemplo, una operación que antes podía rondar unos 42 segundos para una configuración concreta con dos L40 de 48 GB bajaba a unos 2 segundos. Es un dato muy orientado a cargas AI/ML, pero sirve bien para entender por dónde va la mejora.
Qué máquinas virtuales no son compatibles con FSR
Y aquí vienen las excepciones, que son las que conviene revisar antes de dar nada por supuesto.
VMware indica que no son compatibles con FSR las VMs que usan vSphere Fault Tolerance, las que van con DirectPath I/O y también los vSphere Pods. En esos casos, la remediación debe hacerse por otra vía, ya sea migrando la carga o reiniciándola para que coja el nuevo estado.
También quedan fuera las VMs que participan en configuraciones de shared-disk clustering, por ejemplo ciertos escenarios de Microsoft SQL Server FCI. Estas tampoco soportan FSR.
Un detalle interesante es que la presencia de VMs incompatibles no bloquea por sí sola todo el Live Patch. VMware explica que el compliance scan de Lifecycle Manager reporta esas VMs y el motivo, y que tras la remediación los hosts pueden seguir apareciendo fuera de cumplimiento hasta que esas máquinas se migren o se reinicien.
Limitaciones actuales de Live Patch en vSphere 9
Aquí también hay letra pequeña.
VMware indica que Live Patch sí es compatible con clústeres vSAN, lo cual es una buena noticia porque es precisamente uno de los entornos donde más interesa reducir mantenimiento y movimientos innecesarios. Pero también dejan claro que los vSAN witness nodes no son compatibles con Live Patch y que, al parchearlos, harán reboot completo.
Otra limitación importante es la de TPM y DPU. VMware sigue indicando que, por ahora, los hosts que usan TPM y/o DPU no son compatibles con Live Patch. Esto ya aparecía en la información inicial de la funcionalidad y sigue estando presente en la documentación y el contenido técnico publicado alrededor de esta evolución.
Esto no significa que no debas usar TPM, ni mucho menos. Significa simplemente que, si buscas exprimir Live Patch, tienes que tener esta limitación muy presente porque cambia bastante el resultado esperado.
Qué revisaría yo antes de aplicarlo
Confirmar que el clúster está donde tiene que estar
Lo primero sería confirmar versión y modelo de lifecycle. Si el entorno no está ya en la rama correcta y no usa image-based lifecycle management, no tiene sentido hablar de Live Patch como si fuera darle a un botón y ya. VMware lo liga claramente a ese modelo.
Confirmar que el parche concreto es Live Patch capable
Esto parece obvio, pero merece decirse. No basta con que el entorno sea nuevo. Hay que revisar si el parche concreto soporta Live Patch. VMware lo refleja tanto en las release notes como en la interfaz de Lifecycle Manager.
Mirar qué servicios o daemons se van a reiniciar
Aquí es donde vLCM ayuda bastante. VMware explica que Lifecycle Manager informa de los servicios o daemons que se reiniciarán durante la remediación y también de las VMs incompatibles con FSR. Eso es exactamente lo que yo miraría antes de darle a remediar en un entorno serio.
Revisar si hay VMs incompatibles con FSR
Si en el host tienes FT, DirectPath I/O, Pods o clustering con discos compartidos, ya sabes que ahí no vas a tener un comportamiento tan limpio como en una VM normal. Esto no invalida la funcionalidad, pero sí cambia bastante lo que tendrás que hacer después para dejar todo conforme.
Tener claro el contexto del clúster
Si el clúster es vSAN, perfecto, pero recuerda el tema de los witness. Si los hosts usan TPM o DPU, cuenta con que Live Patch no te va a aplicar como te gustaría. Y si el entorno es mixto o heredado, yo primero pondría orden antes de vender esto como un cambio transparente.
Problemas comunes o falsas expectativas
El primer error aquí es pensar que Live Patch vale para cualquier parche. No es así. VMware insiste en que solo ciertos parches entran por esta vía y que hay que comprobarlo tanto en las release notes como en Lifecycle Manager.
El segundo error es pensar que “sin evacuar hosts” significa “impacto cero”. Tampoco es así. Puede haber reinicios de daemons, un host puede verse brevemente desconectado en vCenter y algunas VMs pueden necesitar FSR.
El tercero es olvidar las incompatibilidades. Si tienes VMs que no soportan FSR, luego no tiene sentido sorprenderse porque el host siga marcando falta de compliance hasta que las migres o las reinicies.
Y el cuarto es intentar montar esto sobre una base antigua o mal ordenada. Si el clúster sigue con baselines o vienes de un esquema heredado sin pasar a imágenes, lo primero no es Live Patch. Lo primero es dejar bien planteado el lifecycle.
Conclusión
Sobre el papel, Live Patch en vSphere 9 pinta bastante más serio que en su primera versión. No porque haga magia, sino porque ahora cubre más partes del host y eso permite reducir bastante la necesidad de evacuar máquinas virtuales para aplicar ciertos parches. Ahí sí hay una mejora real.
Ahora bien, yo no lo vendería como “parcheo sin impacto” a secas. Lo vendería como una forma mucho más eficiente de parchear cuando el parche, el clúster y las VMs encajan con el escenario soportado. Si no revisas eso antes, es fácil llevarse una idea equivocada de la funcionalidad.
Yo de momento sigo probándolo en mi laboratorio, porque este tipo de cosas prefiero verlas funcionando antes de dar una opinión más cerrada. Sobre el papel pinta muy bien y desde luego es una de las mejoras más interesantes de vSphere 9, pero quiero validar bien su comportamiento real.
Si consigo avanzar con las pruebas, intentaré traeros también un paso a paso más práctico, con capturas y alguna prueba real en lab para verlo mejor.
VMware ha ampliado bastante esta capacidad en vSphere/VCF 9.0, según la documentación oficial de VMware.
Aquí te dejo un enlace sobre vSphere Configuration Profiles que es bastante interesante
Espero que os sirva