La tabla de ciclo de vida de la documentación oficial de Proxmox es de las cosas más aburridas que se pueden leer un miércoles, y también de las más útiles: la rama 8 —la que se instaló en casi todo lo que se montó entre 2023 y 2025— tiene puesto el fin de vida en agosto de 2026. Es decir, dentro de poco más de treinta días. La reacción habitual es bloquear un fin de semana de agosto y saltar a la 9. Nosotros vamos a decir lo contrario: para varios clusters, actualizar en agosto es peor idea que llegar tarde.
No porque la 9 sea mala —la usamos en producción y ya escribimos el checklist de hardening que aplicamos a cada cluster 9.2— sino porque la fecha límite empuja a hacer en un fin de semana algo que, según cómo esté montado tu entorno, son dos proyectos encadenados. Y porque el salto tiene una asimetría de la que casi nadie habla y que se lleva por delante el plan de vuelta atrás.
Qué se acaba exactamente (y qué no)
Conviene ser preciso, porque aquí se vende mucho miedo. La tabla de soporte del FAQ de Proxmox dice esto:
Fíjate en que la documentación oficial habla de mes, no de día: «2026-08». Verás por ahí el 31 de agosto citado con mucha seguridad; nosotros no lo hemos encontrado en ninguna página de Proxmox. Es más: el propio wiki de la actualización, en su apartado sobre los contenedores que usan cgroup v1, escribe otra cosa —«el ciclo de soporte restante de Proxmox VE 8 (estimated EOL is July 2026)»—. Si la documentación del fabricante no se pone de acuerdo consigo misma en un mes, tú tampoco deberías planificar al día. El 1 de septiembre no se apaga nada, no caduca ninguna licencia y tu cluster sigue arrancando igual. Lo que deja de llegar son los paquetes nuevos: correcciones del kernel de Proxmox, de QEMU, de los propios pve-*.
Y ahí hay un matiz que casi nadie cuenta bien. Debian 12 (bookworm) terminó su soporte de seguridad regular el 12 de julio de 2026 y pasó a manos del equipo de LTS, que lo mantiene hasta el 30 de junio de 2028. Suena a red de seguridad, y para los paquetes de Debian lo es. Pero Debian LTS mantiene paquetes de Debian, y el hipervisor no lo es: pve-manager, qemu-server, el kernel de Proxmox o el empaquetado de Ceph salen de los repositorios de Proxmox. Cuando la rama 8 cae, esa parte —la que ejecuta tus máquinas— deja de recibir correcciones. Sigues teniendo parches de OpenSSL; no de tu hipervisor.
La asimetría que te deja sin marcha atrás
El wiki oficial del salto 8→9 lo dice sin dramatismo, en una línea que se lee rápido y se entiende tarde: migrar una VM o un contenedor de una versión antigua a una nueva siempre va a funcionar; al revés «puede funcionar, pero por lo general no está soportado». Traducido a la noche del sábado: en cuanto actualizas el primer nodo y le mueves carga encima, ya no puedes contar con devolver ese trabajo al nodo que sigue en la 8. Quizá funcione. Pero «quizá funcione» no es un plan de vuelta atrás.
Eso cambia la naturaleza del plan B. Mucha gente entra en la ventana pensando que su vuelta atrás es «migro las VMs al otro nodo y ya». No: tu vuelta atrás es restaurar desde backup, con el tiempo de restauración que eso implica y con el dato de las horas transcurridas por medio. Si no has cronometrado nunca cuánto tarda tu restauración completa de las tres máquinas que de verdad importan, no tienes plan B: tienes una esperanza.
Si corres Ceph, no es una ventana: son dos
El requisito está en el wiki, en negrita y en su sitio: si tienes Ceph hiperconvergente en Quincy o en Reef, hay que llevarlo a Ceph 19.2 Squid antes de empezar la actualización de Proxmox. Antes, no durante. Y actualizar Ceph en un cluster con datos encima es un proyecto con su propio ritmo: OSD a OSD, mirando el estado del cluster entre paso y paso, sin prisa, porque la prisa en Ceph se paga en backfill. Quien tenga esto pendiente y esté mirando el calendario de agosto ya sabe la respuesta: no cabe. Cabe la primera mitad, y la segunda en septiembre.
Comprobarlo cuesta un comando y evita una conversación fea a mitad de la ventana:
pve8to9 viene en los paquetes recientes de la 8.4 y solo comprueba y reporta: por defecto no toca nada. Es la herramienta más infravalorada de todo el proceso. Pásala hoy, no la noche de la ventana: su valor está en darte la lista de deberes con tiempo suficiente para hacerlos.
Los contenedores que no van a arrancar
Este es el bloqueante que aparece siempre tarde. Proxmox VE 9 no soporta contenedores con systemd 230 o anterior —una versión de 2016—, lo que en la práctica significa CentOS 7, Ubuntu 16.04 y compañía. El wiki lo dice claro. Y esos contenedores existen: son justo los que nadie quiere tocar, con una aplicación cuyo autor se jubiló hace años.
Resolverlo significa llevar esa aplicación a un sistema operativo nuevo, con sus pruebas y su acuerdo con quien la usa. Si lo descubres el sábado a las once de la noche, tu opción realista es dejar ese contenedor donde está, en un nodo que no actualizas, y quedarte con un cluster a medias. Si lo descubres hoy, tienes un mes para decidir si esa aplicación merece una migración, una máquina virtual dedicada o una jubilación.
Las seis señales de que este agosto NO toca
Nuestra regla es simple: si se cumple una sola de estas seis, la actualización se mueve a septiembre y se monta un plan de contención para el mes que queda sin parches. Llegar tarde con el cluster en pie es recuperable; llegar puntual con un nodo que no arranca, en agosto y con media plantilla de vacaciones, no.
- ✗Ceph sigue en Quincy o Reef. Primero Squid, y con su propia ventana. Encadenar las dos cosas en una noche es como cambiar el motor y las ruedas a la vez, en marcha.
- ✗Hay contenedores con systemd viejo sin destino decidido. No arrancarán, y decidirlo de madrugada sale caro.
- ✗No tienes acceso fuera de banda al nodo (IPMI, iDRAC, iLO o una consola física a la que puedas ir). El wiki lo recomienda explícitamente, y hay un motivo: el kernel nuevo puede renombrar tarjetas de red, y un nodo con la red mal configurada solo se arregla por consola.
- ✗La última restauración probada es «la de siempre», sin fecha ni cronómetro. Aquí el plan B pasa por restaurar, y una restauración que nadie ha cronometrado todavía no cuenta como plan.
- ✗
pve8to9 --fulldevuelve avisos que no entiendes. Cada aviso sin resolver es una sorpresa aplazada, y la distancia entre «esto no lo entiendo» y «esto no arranca» son unas cuantas horas. - ✗La ventana cae pegada a un cierre de mes, una nómina o un pico de negocio, o el equipo que sabe de esto está de vacaciones. Agosto es agosto. La disponibilidad de la gente forma parte del diseño de la ventana, igual que el quórum.
Cómo lo hacemos nosotros
Cuando hay hierro y capacidad de sobra, no hacemos actualización in-place: preferimos vaciar el nodo —migrar su carga a los demás—, dejarlo limpio, actualizarlo o reinstalarlo, devolverle trabajo y pasar al siguiente. Es más lento y más aburrido, y a cambio el nodo que estás tocando no tiene nada encima cuando se rompe. Es la misma lógica de siempre: separa el cambio del riesgo. Cuando no hay holgura para vaciar un nodo entero, el in-place del wiki está perfectamente bien y funciona; lo que cambia es que entonces sí necesitas todo lo anterior resuelto de antemano.
El resto de la disciplina, en corto, y todo sale del wiki oficial más lo que nos ha ido enseñando el oficio:
- ✓Todos los nodos en la última 8.4 primero (el wiki pide estar en la última 8.4, y para los repositorios menciona
pve-manager8.4.1 o superior). Un cluster con versiones dispares se ordena antes de empezar, no durante. - ✓Espacio libre en la raíz: el wiki pide 5 GB y recomienda más de 10. Se comprueba con el cluster tranquilo, mucho antes de lanzar el
dist-upgrade. - ✓Sesión dentro de
tmuxoscreen. Una actualización mayor no se hace en una SSH suelta que muere con la conexión del portátil. - ✓Un nodo, comprobación, respiro. Si el primero da guerra, la ventana se cierra ahí y el cluster sigue con mayoría en la 8. No hay premio por terminar de madrugada.
- ✓Nunca dos clusters el mismo fin de semana. Si algo raro aparece, quieres que aparezca una vez y no tres.
Y dos avisos concretos del wiki que valen su peso: en sistemas con UEFI y LVM puede hacer falta instalar el metapaquete grub-efi-amd64, y hay thin pools de LVM que después del salto necesitan un lvconvert --repair. Ninguna de las dos cosas es grave si sabes que existen; las dos lo parecen mucho a las dos de la mañana.
Si no llegas: plan de contención honesto
Decidir «en septiembre» es legítimo, pero no es gratis y no se decide callando. Lo que hacemos con un cluster que se va a quedar unas semanas fuera de soporte:
- 1.Fecha escrita en el calendario, con nombre y responsable. Los aplazamientos que se quedan sin fecha acaban durando años — ya escribimos sobre esa misma trampa a propósito de los silencios de monitorización sin caducidad.
- 2.El panel de administración, fuera de Internet. Sin parches del hipervisor, la superficie expuesta importa el doble.
- 3.Copias verificadas y con una restauración cronometrada de verdad antes de la nueva ventana. Es el trabajo que vas a necesitar sí o sí.
- 4.Y el trabajo de agosto es el de preparación:
pve8to9 --full, inventario de contenedores, Ceph a Squid. Llegas a septiembre con la ventana ya casi hecha.
Hay un caso en el que sí decimos «no lo hagas ahora, cómpralo bien»: si el plan pasa por sustituir hardware para hacer sitio a la migración, este año la memoria no acompaña. Lo contamos con los números de mercado en lo que la IA le ha hecho al precio de la RAM. Y si el cuello de botella es de almacenamiento, la decisión de diseño de Ceph pesa más que la versión: la tienes desmenuzada en réplica 3 frente a erasure coding con la cuenta completa.
Los treinta días que quedan, repartidos
Si vas a ir a por ello, este es el reparto que nos parece realista contando desde hoy, 29 de julio. Esta semana: pve8to9 --full en todos los nodos, inventario de contenedores por versión de sistema operativo, comprobar la versión de Ceph y el espacio libre en la raíz. Todo es lectura, no toca nada, se puede hacer un martes por la tarde. Primera quincena de agosto: resolver lo que haya salido —Ceph a Squid, contenedores viejos, avisos del comprobador—, y probar una restauración con cronómetro. Segunda quincena: el salto, empezando por el nodo de menos riesgo, un nodo por ventana, con el resto del cluster en pie. Si en cualquier punto del camino algo no está, se para y se va a septiembre. Esa es la parte importante del plan.
En corto
La fecha de agosto es real y hay que tomársela en serio: sin ella, esta actualización se quedaría dormida dos años más. Pero una fecha no es un plan, y el error caro de este verano no va a ser llegar en septiembre: va a ser entrar en la ventana sin haber pasado el comprobador, sin saber qué contenedores no arrancan y creyendo que se puede volver atrás moviendo una VM. Eso último es lo único que de verdad no se puede deshacer.
Fuentes (verificadas): tabla de ciclo de vida de versiones (PVE 9 / Debian 13 / 2025-08; PVE 8 / Debian 12 / 2023-06 / fin de vida 2026-08; PVE 7 / 2024-07) — FAQ oficial de Proxmox VE. Requisitos y problemas conocidos del salto (estar en la última 8.4 con pve-manager 8.4.1 o superior para los repositorios, Ceph 19.2 Squid antes de empezar, 5 GB libres en la raíz y más de 10 recomendados, contenedores con systemd 230 o anterior no soportados, cambios de nombre de interfaces de red, grub-efi-amd64 en UEFI+LVM, lvconvert --repair, pve8to9 --full, migración en vivo garantizada solo de versión antigua a nueva) — wiki oficial «Upgrade from 8 to 9». La contradicción del propio fabricante («estimated EOL is July 2026», en el apartado de eliminación de cgroup v1 del mismo wiki de actualización). Fechas de Debian 12 (fin del soporte regular el 12-07-2026, tres años después de la publicación inicial; LTS hasta el 30-06-2028) — anuncio oficial de Debian y wiki de Debian LTS. El día exacto del fin de vida (31 de agosto) circula en medios y agregadores, pero no lo hemos podido confirmar en documentación de Proxmox: por eso hablamos de mes. El criterio de las seis señales, el reparto de los treinta días y la forma de trabajar por nodo vaciado son nuestros.
¿Tienes que saltar a Proxmox VE 9 y prefieres no hacerlo a solas?
En everyWAN operamos infraestructura Proxmox VE con Ceph en producción, repartida en varios datacenters, desde las ramas 3.x. Revisamos el estado real de tu cluster, te decimos si llega a agosto y planificamos la ventana contigo — incluida la parte de decirte que no la hagas todavía.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN