Proxmox VE 8 EOL: ¿conviene actualizar ya a Proxmox VE 9?

Proxmox VE 8 llega al final de su vida con soporte en agosto de 2026, así que la mayoría de los sistemas que siguen en 8.x ya deberían tener reservada una ventana de actualización a Proxmox VE 9. Si el host está sano, tus copias de seguridad se pueden restaurar y tu almacenamiento y las integraciones de terceros admiten Proxmox VE 9, yo actualizaría en lugar de llevarme a septiembre un hipervisor sin soporte.

He contrastado el ciclo de vida del soporte de Proxmox, los anuncios de Proxmox VE 9.0 y 9.2, la ruta oficial de actualización y el aviso de soporte que ahora ven los usuarios de Proxmox VE 8. Mi referencia aquí son el ciclo de vida publicado y la documentación de Proxmox; las conjeturas de los foros sobre cuánto tiempo seguirán descargables los paquetes antiguos no lo son.

¿Cuándo termina el soporte de Proxmox VE 8?

Proxmox fija el fin de vida de Proxmox VE 8 en agosto de 2026, y los usuarios ya ven un aviso en la interfaz web de que el soporte termina el 31 de agosto de 2026. Proxmox VE 8 llegó en junio de 2023 sobre Debian 12 Bookworm, mientras que Proxmox VE 9 llevó la plataforma a Debian 13 Trixie.

Fin de vida no significa que tu servidor se niegue de repente a arrancar. Tus VMs pueden seguir funcionando el 1 de septiembre, pero a partir de ese día funcionan sin soporte.

En una máquina de laboratorio aislada y fácil de reconstruir, quizá aceptes pasar un tiempo corto en una versión sin soporte. Un host de producción, un plano de gestión accesible desde internet o un clúster con cargas de trabajo del negocio tienen un perfil de riesgo distinto. Cuando una rama de un hipervisor se queda sin soporte, te toca a ti explicar por qué se acepta un problema conocido de seguridad o fiabilidad.

Si todavía estás decidiendo si Proxmox es la plataforma adecuada a largo plazo, la sección de Proxmox es mejor sitio para evaluarlo que dejar que una fecha de EOL decida por ti.

¿Qué pasa si sigo con Proxmox VE 8 después del EOL?

El efecto inmediato es que la rama Proxmox VE 8 deja de recibir actualizaciones de seguridad con soporte y correcciones de fallos críticos. Tu clúster no se apaga, y por eso los sistemas en EOL pueden parecer perfectamente normales durante semanas o meses después de la fecha.

El riesgo se acumula sin que nada se rompa a la vista. Puede aparecer una vulnerabilidad nueva en QEMU, el kernel, el almacenamiento, la red o la gestión después de tu última actualización con soporte, y entonces te quedan menos opciones buenas, porque puede que la corrección solo exista en la línea Proxmox VE 9 con soporte.

También hay un coste operativo. Los proveedores de copias de seguridad, las herramientas de monitoreo, los providers de Terraform, los fabricantes de hardware y los equipos de soporte suelen probar contra versiones con soporte. Cuanto más tiempo sigas en Proxmox VE 8, más probable es que te topes con un problema en el que la primera recomendación sea simplemente actualizar antes de que nadie dedique tiempo a depurarlo.

Yo no convertiría el 31 de agosto en una fecha límite de pánico, y tampoco lo trataría como una tarea de limpieza opcional. Si necesitas una semana más para terminar una prueba de restauración y un plan de mantenimiento, tómate la semana. Si necesitas seis meses más porque nadie se hace cargo de la actualización, tienes un problema de proceso.

¿Está Proxmox VE 9 lo bastante maduro para actualizar ya?

Sí. Proxmox VE 9 lleva cerca de un año en producción y Proxmox VE 9.2 salió en mayo de 2026, así que ya no eliges entre una rama 8.x madura y una 9.0 recién salida ayer.

El anuncio original de Proxmox VE 9.0 admitía expresamente actualizar desde la última versión de Proxmox VE 8. En mayo de 2026, Proxmox VE 9.2 se había convertido en la versión de funciones actual de la serie 9.x, con indicaciones actualizadas para los usuarios de Ceph y el mismo recordatorio de que el soporte de Proxmox VE 8.4 termina en agosto de 2026.

Aun así, cada entorno necesita una comprobación antes de actualizar. Un hipervisor puede ser estable mientras una dependencia de tu pila no está lista, y el software de copias de seguridad es el ejemplo obvio. Si tu proveedor de backup solo certifica Proxmox VE 9.0 o 9.1, pasar directamente a 9.2 puede dejarte sin soporte en ese punto aunque Proxmox considere que 9.2 está lista.

Antes de tocar producción, haz inventario de todo lo que habla con la API de Proxmox, instala paquetes en el host, depende de un kernel concreto o lee el almacenamiento directamente. Eso incluye agentes de backup, exportadores de monitoreo, configuraciones de passthrough de GPU, módulos DKMS personalizados, scripts de automatización, integraciones con UPS y plugins de almacenamiento externo.

¿Qué debo revisar antes de actualizar de Proxmox VE 8 a 9?

La actualización más segura de Proxmox VE 8 a 9 empieza por tener confianza en la restauración, mucho antes de cualquier comando apt. Una tarea de backup correcta demuestra que los datos se escribieron en algún sitio. Una prueba de restauración correcta demuestra que puedes recuperar la carga de trabajo.

Mi lista previa sería esta:

• Actualiza todos los nodos a los últimos paquetes disponibles de Proxmox VE 8.4 antes de cambiar de versión mayor.
• Confirma que el clúster está sano y que ninguna operación de recuperación de almacenamiento, replicación, scrub o migración tiene ya problemas.
• Ejecuta el comprobador pve8to9 --full que ofrece Proxmox y resuelve los fallos antes de seguir.
• Comprueba que tienes espacio libre suficiente en el sistema de archivos raíz para la actualización de la distribución.
• Revisa con atención los avisos del gestor de arranque. Las actualizaciones de Proxmox VE 8 a 9 tienen detalles concretos de systemd boot y EFI que el comprobador está pensado para señalar.
• Anota tus repositorios y quita o desactiva los repositorios de terceros que no tengan un camino hacia Debian 13 Trixie.
• Prueba al menos la restauración de una VM y, si usas contenedores, la de un LXC.
• Confirma que tu producto de backup admite exactamente la versión de Proxmox VE 9 que piensas ejecutar.

Si tu problema de actualización es en realidad un problema de diseño del almacenamiento, arréglalo por separado. La sección de almacenamiento es mejor sitio para trabajar la arquitectura de ZFS, Ceph y backup que intentar cambiar el almacenamiento y la versión del hipervisor en la misma ventana de mantenimiento.

¿Conviene actualizar los nodos Proxmox de uno en uno?

Sí, un clúster de varios nodos normalmente debería actualizarse siguiendo una secuencia controlada de nodos, para poder sacar las cargas de trabajo del nodo que se está cambiando. Eso limita el tamaño de cada dominio de fallo y te da un punto limpio para parar si el primer nodo actualizado deja ver un problema de integración.

En cada nodo, yo migraría o detendría sus invitados, confirmaría que el nodo está tranquilo, volvería a ejecutar la comprobación previa, haría la actualización según la guía oficial, reiniciaría y luego validaría la red, el almacenamiento, el estado de HA, la visibilidad de los backups y el funcionamiento de los invitados antes de pasar al siguiente nodo.

No uses "carga la interfaz web" como criterio de éxito. Revisa bridges, bonds, la red con VLAN, los montajes de almacenamiento, las tareas de replicación, los backups programados, los agentes de invitado, los dispositivos en passthrough y el monitoreo, porque el fallo que importa suele estar fuera del panel de Proxmox.

Un host independiente tiene menos piezas móviles, pero menos margen de error, ya que no hay adonde migrar en vivo las cargas de trabajo. En ese caso me importan todavía más las copias de seguridad probadas, el acceso remoto a consola y una vía de recuperación arrancable.

¿Qué cambia si mi clúster Proxmox usa Ceph?

Un clúster Proxmox con Ceph necesita un plan de actualización del almacenamiento antes del cambio de versión mayor de Proxmox. Proxmox indica que un clúster Proxmox VE 8.4 con Ceph Reef debe actualizar primero Ceph de Reef a Squid y después actualizar Proxmox VE de 8.4 a 9.x.

Es un orden fácil de pasar por alto, porque "actualizar Proxmox" suena a una sola tarea. En un clúster hiperconvergente son al menos dos cambios de plataforma enlazados, y la salud de Ceph es lo que mantiene disponibles los discos de las VMs mientras los hosts pasan por el mantenimiento.

Yo no juntaría un cambio de versión de Ceph, un cambio de versión mayor de Proxmox, firmware nuevo en las tarjetas de red y un rediseño de la red en un fin de semana heroico. Los cambios separados te dan mejores pruebas cuando algo falla.

Quien opere Ceph también debería prestar atención a la versión de seguridad actual Ceph 19.2.6 y a sus notas de actualización. Lo trato aparte en la guía de actualización a Ceph 19.2.6, porque la capa de almacenamiento merece su propia comprobación previa y no un párrafo enterrado dentro de un artículo sobre actualizar Proxmox.

¿Actualizo ya o espero un poco más?

Yo actualizaría ya si tu entorno está en los paquetes actuales de Proxmox VE 8.4, tus pruebas de restauración salen bien y tus dependencias de backup y hardware admiten Proxmox VE 9.2. La ventana de soporte que le queda a Proxmox VE 8 ya es demasiado corta para justificar que se aplace por comodidad una migración que está lista.

Esperaría un poco si el comprobador de actualización informa de fallos sin resolver, tu clúster Ceph no está sano, tu única copia de seguridad nunca se ha restaurado o una integración crítica de un proveedor todavía no admite la versión de destino. En esos casos, quita el bloqueo rápido y no pierdas de vista la fecha de EOL.

Si este fuera mi clúster de producción el 21 de agosto de 2026, querría el primer nodo actualizado antes de la última semana de agosto, con calendario suficiente para parar tras el primer nodo si aparece algo inesperado. Elige una ventana que te deje margen para diagnosticar problemas, y no dejes que termine cinco minutos antes que el soporte.