Durante años, hablar de actualizar hosts en VMware era hablar de baselines. Era lo normal. Importabas una ISO, montabas tu baseline, la adjuntabas al clúster o al host, pasabas compliance y remediabas. Y listo. De hecho, muchos seguimos teniendo esa forma de trabajar muy metida en la cabeza porque durante bastante tiempo ha funcionado bien.
El problema es que en vSphere 9 esa forma de pensar ya no vale igual. VMware ha dejado bastante claro que los clústeres y hosts gestionados por baselines ya no están soportados en vSphere 9 y que el camino es image-based lifecycle management con vSphere Lifecycle Manager. Dicho más claro: si quieres ir de verdad a ESX 9, toca cambiar de modelo.
Tal y como explica VMware en la información oficial de vSphere 9, los clústeres gestionados por baselines quedan fuera de este modelo.
Y esto no es solo un cambio de nombre ni una manía nueva del producto. Cambia la forma de pensar el ciclo de vida del host. Con imágenes ya no trabajas con un parche suelto o una baseline concreta, sino con una especificación de software deseada para el clúster. Ese es el punto importante.
Qué cambia con los baselines en VMware vSphere 9
Con el modelo clásico de baselines, tú vas aplicando actualizaciones o upgrades sobre los hosts a partir de líneas base y grupos de líneas base. Es un enfoque que durante años ha sido válido y muy conocido, pero que arrastra una operativa más fragmentada. En cambio, con las imágenes de vSphere Lifecycle Manager trabajas con una imagen única que representa el estado software que quieres tener en todos los hosts del clúster. VMware lo define precisamente así: una especificación de software deseada que se aplica al conjunto de hosts.
Esto tiene una consecuencia práctica bastante importante. El modelo de imágenes busca homogeneidad de clúster, simplifica las operaciones de instalación, actualización, upgrade y parcheo, y además te permite meter en la misma definición cosas como el vendor add-on, firmware, drivers y otros componentes necesarios. En el contenido oficial reciente sobre VCF 9 incluso remarcan que una de las ventajas de las imágenes es precisamente poder gestionar drivers personalizados, firmware y vendor add-ons a nivel de clúster.
En vSphere 9 esto va todavía un paso más allá. VMware añadió soporte para mixed hardware clusters con varias definiciones adicionales de imagen dentro del mismo clúster, manteniendo una base ESX común y ajustando add-ons, firmware y HSM según el hardware. Eso te da bastante más juego que el enfoque antiguo cuando el entorno real no es tan limpio como nos gustaría.
Requisitos
Aquí hay un punto importante, porque si esta base no está bien, el resto da un poco igual.
VMware indica que vSphere 9 soporta upgrade directo desde vSphere 8.0, pero no desde 7.0. También deja claro que vCenter 9.0 ya no gestiona hosts ESX 7.0 o anteriores y que la versión mínima de ESX que puede gestionar es ESX 8.0. Así que si alguien sigue mezclando vCenter nuevo con hosts antiguos pensando en hacerlo poco a poco como antes, aquí ya hay una primera limitación seria.
La segunda es la más importante para este artículo: los clústeres y hosts baseline-managed no están soportados en vSphere 9. Los entornos que todavía van por ese modelo tienen que pasar a image-based lifecycle management. VMware también indica que los clústeres y hosts existentes en ESX 8.x que aún estén con baselines pueden seguir gestionándose con vLCM, pero deben convertirse a imágenes antes de subir a ESX 9. Además, los clústeres nuevos ya no pueden crearse en baseline mode aunque estén en ESX 8.
Arquitectura o escenario típico
Para verlo más claro, yo lo bajaría a un escenario bastante normal de laboratorio o de producción pequeña:
vCenter 8.x o 9
└── Cluster VMware
├── Host 1
├── Host 2
└── Host 3
Si ese clúster sigue funcionando con baselines, en vSphere 9 te vas a encontrar con que ya no es el modelo soportado para seguir avanzando. La idea ahora es que ese clúster pase a gestionarse con una imagen que defina el estado deseado del software de host para todo el conjunto. VMware lo plantea justamente así cuando habla de usar una sola imagen para todos los hosts del clúster y mantener una gestión homogénea a nivel cluster-wide.
Cómo saber si tu entorno sigue en baselines
Aquí no hace falta ponerse demasiado filosófico. Si tu forma habitual de trabajar sigue siendo crear baselines, adjuntarlas al clúster o al host y luego pasar check compliance para remediar, sigues en el modelo clásico. Es exactamente el enfoque que VMware llevaba años usando y que además tú mismo ya tenías documentado en el blog cuando actualizaste de ESXi 6.7 a 7 con Lifecycle Manager.
Si en cambio tu clúster se gestiona con una única imagen y la remediación compara los hosts con esa especificación de software deseada, ya estás en el enfoque nuevo. VMware define justamente las imágenes de vLCM como ese desired software state aplicado al clúster.
Traducido a algo más práctico: si sigues pensando en “adjuntar baseline”, estás en el modelo que ya toca dejar atrás. Si ya piensas en “definir imagen del clúster”, estás en el camino que VMware quiere para vSphere 9.
Qué revisaría yo antes de pasar de baselines a imágenes
Revisar primero la versión real del entorno
Antes de tocar nada, yo confirmaría qué tienes exactamente en producción. Si sigues con vCenter 7 o con hosts ESX 7, no estás todavía en el punto de hablar de vSphere 9 como si fuera un salto directo. VMware marca un camino bastante claro: vCenter 9 soporta upgrade directo desde 8.0 y no gestiona hosts 7.0 o anteriores.
Entender qué metías antes en baselines y qué tendrás que llevar a la imagen
Aquí está una de las partes que más merece la pena revisar con calma. Con el modelo de imágenes no solo piensas en la versión base de ESX. También tienes que pensar en vendor add-ons, controladores, firmware y componentes adicionales. VMware vende precisamente esa parte como una de las ventajas del nuevo enfoque: llevar toda esa definición a nivel de clúster y dejarla mucho más consistente.
Ver si tu hardware es homogéneo o no
Este punto antes dolía más. En vSphere 9, vLCM soporta clústeres con hardware mixto y varias definiciones adicionales de imagen dentro del mismo clúster. Eso no significa que haya que hacerlo siempre así, pero sí que cambia bastante el juego cuando tienes nodos de distintos fabricantes o generaciones distintas que antes complicaban mucho más el lifecycle.
Hacer la prueba primero en lab
Esto parece el consejo de siempre, pero aquí tiene todo el sentido del mundo. Cambiar el modelo de lifecycle no es como meter un parche suelto. Afecta a cómo vas a gestionar a partir de ahora upgrades, compliance y remediación del clúster. Además, en la documentación y en los contenidos recientes sobre convergencia a VCF 9 VMware insiste mucho en correr validaciones y remediar prerequisitos antes de meterse en el cambio.
Qué ventajas tiene el nuevo modelo aunque al principio dé pereza
La primera ventaja es que, una vez lo entiendes, el modelo de imágenes es bastante más limpio. En lugar de ir acumulando lógica de baselines, baselines groups y excepciones, defines el estado deseado del clúster y remediar consiste básicamente en alinear los hosts con esa especificación. VMware lleva tiempo empujando esta idea como forma más simple y unificada de gestionar patching, upgrades y software de host.
La segunda es que este modelo encaja mejor con otras piezas nuevas de vSphere. Por ejemplo, Live Patch en vSphere 9 se apoya en clústeres gestionados con imágenes, no con baselines. Es decir, no estamos hablando solo de una recomendación de estilo, sino de una base necesaria para poder aprovechar nuevas capacidades del producto.
Y la tercera es que VMware está enseñando de forma bastante clara hacia dónde va la plataforma. Igual que ya está empujando vSphere Configuration Profiles frente a Host Profiles, también está dejando atrás el modelo de baselines en favor de desired state e imágenes. Viendo la dirección del producto, yo no invertiría mucho en seguir refinando un modelo que ya va de salida.
Problemas comunes o falsas expectativas
El primer error aquí es pensar que esto solo afecta a quien vaya a montar VMware Cloud Foundation. No exactamente. Es verdad que gran parte de la documentación reciente lo empuja mucho desde VCF 9, pero el propio contenido oficial de vSphere 9 deja claro que los clústeres baseline-managed ya no son compatibles en esa versión.
El segundo error es pensar que pasar a imágenes es solo “otra forma de hacer lo mismo”. No del todo. El cambio conceptual es importante porque pasas de un enfoque de actualización basado en líneas base a uno basado en desired software specification. Eso luego afecta a cómo compones, validas y remediarás el clúster.
Y el tercero es quedarse con la idea de que si hoy todo funciona no merece la pena tocar nada. El problema es que ese razonamiento te deja bloqueado en cuanto quieras dar el salto a ESX 9 o aprovechar funcionalidades nuevas ligadas al modelo de imágenes. Ahí es donde te estalla el cambio en la cara en el peor momento posible.
Checklist final
Antes de tocar nada, yo revisaría cinco cosas. Primero, la versión real de vCenter y de los hosts. Segundo, si el clúster sigue todavía con baselines o ya está en single image. Tercero, qué drivers, vendor add-ons y firmware necesitas contemplar en la nueva imagen. Cuarto, si tu hardware es homogéneo o vas a necesitar aprovechar las capacidades nuevas para clústeres mixtos. Y quinto, si puedes probar el cambio primero en laboratorio antes de convertirlo en una tarea de tarde en producción. Todo eso encaja con la dirección oficial de vSphere 9 y con las recomendaciones que VMware está repitiendo alrededor de vLCM e imágenes.
Conclusión
No creo que el mensaje aquí sea que los baselines fueran malos. Durante años han servido y nos han sacado el trabajo adelante sin problema. El tema es otro: en vSphere 9 ya no son el camino. VMware ha marcado bastante bien la dirección y esa dirección pasa por vSphere Lifecycle Manager con imágenes.
Yo me quedaría con una idea muy simple. Si tu entorno sigue en baselines, no es tanto que tengas que correr hoy mismo a cambiarlos, sino que ya conviene empezar a planificarlo bien. Mejor hacerlo con calma, entendiendo cómo quedará tu imagen, qué dependencias tienes y qué hardware hay en el clúster, que esperar a que el siguiente upgrade te obligue a hacerlo deprisa y mal. Esa, para mí, es la parte importante.
Si quieres ver cómo era el enfoque más clásico, aquí conté hace tiempo cómo actualizar VMware ESXi 6.7 a 7 con Lifecycle Manager.
Espero que os sirva