Proxmox VE 8 caduca en agosto: Debian te seguirá parcheando, el hipervisor no

El día que Proxmox VE 8 se quede sin soporte no se va a caer nada: ni un nodo, ni una máquina virtual, ni la interfaz web del 8006. Un parquímetro caducado tampoco inmoviliza el coche. La diferencia es que el parquímetro al menos pone EXPIRED en la pantalla, y tu nodo va a seguir diciéndote que está todo al día. Debian le seguirá enviando parches de seguridad hasta junio de 2028; Proxmox deja de enviárselos este mes.

La tabla oficial dice 2026-08. No dice el día

La fuente es la tabla de ciclo de vida que mantiene Martin Maurer, responsable del proyecto Proxmox VE, y la fila de la versión 8 tiene cuatro casillas: primera versión 2023-06, base Debian 12 «Bookworm», fin de soporte de Debian 2026-07 y fin de soporte de Proxmox VE 2026-08. La política que la acompaña cabe en una frase: las versiones de Proxmox VE tienen soporte «al menos mientras la versión de Debian correspondiente sea oldstable».

Media internet lleva semanas escribiendo «31 de agosto». Nosotros también lo damos por bueno como fecha de trabajo —es el último día del mes que pone la tabla—, pero conviene saber que ese día concreto no lo ha publicado Proxmox: publicó el mes. Y para planificar importa menos de lo que parece, porque el fin de soporte no es un interruptor que alguien acciona a medianoche. Es el momento a partir del cual, si aparece un fallo en esa rama, ya no hay nadie al otro lado arreglándolo.

Por qué apt no te va a avisar

Un nodo Proxmox VE 8 se alimenta de dos sitios a la vez. Por un lado, los repositorios de Debian, incluido el de seguridad (bookworm-security). Por otro, el repositorio de Proxmox, sea el de empresa o el pve-no-subscription. Son dos grifos independientes, y no cierran el mismo día.

El de Debian no cierra en agosto. El 12 de julio de 2026, tres años después de la publicación inicial, terminó el soporte ordinario de Debian 12 «Bookworm» y el equipo de LTS tomó el relevo de los de seguridad y publicación; Bookworm LTS llega hasta el 30 de junio de 2028. Lo decisivo es cómo se entrega ese relevo: el proyecto Debian lo describe sin rodeos como «un simple traspaso de responsabilidad» que «reutiliza la misma infraestructura de réplicas» que los equipos habituales. Traducido: no hay que cambiar ni una línea de sources.list. Si ya sigues security.debian.org, las actualizaciones del LTS te llegan solas.

Así que en septiembre harás apt update && apt full-upgrade en un nodo sin soporte y pasará prácticamente lo mismo que en agosto: se descargan paquetes, se instalan parches de seguridad reales y el sistema queda al día. apt no está ahí para decirte que uno de los dos grifos se ha cerrado; te informa de lo que hay disponible, y de Debian va a seguir habiendo durante casi dos años. La señal en la que confías sigue funcionando, y por eso dejas de mirarla.

La mitad que se congela

Lo que deja de recibir arreglos es justo la capa que convierte ese Debian en un hipervisor: pve-manager —la interfaz web del puerto 8006 y su API—, qemu-server, pve-qemu-kvm, pve-container, las utilidades de clúster y los paquetes de Ceph que compila Proxmox. Es también la capa que suele estar expuesta: la interfaz de administración y el plano de gestión del clúster.

Y el kernel, que merece párrafo aparte porque es la confusión más repetida: Proxmox VE es Debian, pero no arranca el kernel de Debian. El paquete proxmox-kernel-* se construye a partir del kernel de Ubuntu. Ya lo desarrollamos con dos CVE concretos en Zapscape y SCTPhantom: tu Proxmox no lleva el kernel de Debian, y aquí la consecuencia es doble. El LTS de Debian no cubre ese kernel —nunca lo ha cubierto, porque no es suyo— y a partir de septiembre tampoco lo cubre Proxmox en la rama 8.

Un aviso de seguridad del kernel Linux en octubre se cerrará en Debian, se cerrará en Proxmox VE 9, y en tu nodo 8 se quedará abierto. Con apt sin nada que decir al respecto.

Un comando que sabe media verdad

Debian trae una herramienta para esto. El paquete debian-security-support instala check-support-status, que revisa lo que tienes instalado y te dice qué paquetes se han quedado fuera de la cobertura de seguridad, porque el LTS no cubre todo el archivo de Debian y esa lista se mueve.

Vale la pena ejecutarlo. Pero hay que entender su límite antes de fiarse del resultado: solo sabe de paquetes de Debian. Sobre pve-manager o proxmox-kernel no va a decir nada, ni bien ni mal, porque no son suyos. Es una herramienta honesta con un punto ciego que resulta ser exactamente el que te importa.

Qué hay al otro lado

La 9.2 salió el 21 de mayo de 2026. Va sobre Debian 13 «Trixie» (13.5), con kernel Linux 7.0 como estable por defecto, QEMU 11.0, LXC 7.0, ZFS 2.4 y Ceph en dos opciones, Squid 19.2.3 y Tentacle 20.2.1. En agosto Proxmox sumó además la edición oficial para arm64 dentro de esa misma familia. Toda la ingeniería está ahí.

De lo que trae, dos cosas cambian el día a día de quien opera un clúster. Una es el balanceo dinámico de carga del planificador de recursos, que migra los invitados gestionados por HA en función de la utilización real de cada nodo; conviene leer bien ese matiz, porque lo que no está en HA se queda donde está. La otra son WireGuard y BGP como nuevos protocolos de fabric en la SDN, con mapas de rutas y listas de prefijos para filtrar.

Hay una tercera que parece menor y para esta ventana concreta es la más útil: la alta disponibilidad se puede desarmar y rearmar en todo el clúster con dos órdenes nuevas del CRM, disarm-ha y arm-ha, para hacer mantenimiento sin provocar un fencing. Quien haya subido un nodo a mano con HA activa sabe por qué se agradecen. Los límites reales de la HA los desmenuzamos en la HA de Proxmox no evita la caída, la acorta.

El camino, en el orden que importa

La actualización es in situ y nodo a nodo; no hay que reinstalar nada. El orden de la guía oficial importa, y bastante:

1. Deja todos los nodos en la última 8.4, con pve-manager en 8.4.1 como mínimo. Desde la 8.2 no se salta directamente.
2. Si tienes Ceph hiperconvergente, súbelo a Squid 19.2 antes de tocar Proxmox. Compruébalo con ceph --version en cada nodo, no en uno.
3. Asegura 5 GB libres en la raíz, y a ser posible más de 10.
4. Ejecuta pve8to9 y después pve8to9 --full. Solo comprueba y avisa: no cambia nada por su cuenta. Lo que salga ahí es tu lista de tareas real.
5. Nodo a nodo: migra fuera lo crítico, cambia los repositorios, apt dist-upgrade, reinicia al kernel nuevo y confirma que ese nodo está bien antes de pasar al siguiente.

Los repositorios cambian de nombre y también de formato. Trixie usa deb822, con ficheros .sources de varias líneas en lugar de las entradas sueltas del sources.list de siempre, y apt se queja si te quedas en el formato antiguo. Hay atajo: apt modernize-sources.

Lo que se rompe

Esto no lo decimos nosotros: está en la lista de problemas conocidos y cambios de la propia guía de actualización. Lo reproducimos porque es donde se va el tiempo de una ventana de mantenimiento.

• «La actualización quiere eliminar el paquete proxmox-ve». Pasa si tienes instalado linux-image-amd64. Se quita antes, con apt remove linux-image-amd64. Es el susto clásico y tiene arreglo de una línea.
• GRUB puede fallar en sistemas con LVM y UEFI. Se resuelve con apt install grub-efi-amd64. Conviene saberlo antes de reiniciar, no después.
• Los nombres de las interfaces de red pueden cambiar. Si tu /etc/network/interfaces dice enp3s0 y al arrancar la tarjeta se llama otra cosa, el nodo vuelve sin red. Para eso existe pve-network-interface-pinning.
• /tmp pasa a ser tmpfs, con hasta la mitad de la memoria. Si algún proceso tuyo escribe cosas grandes ahí, te vas a enterar.
• Se acabó cgroup v1. Los contenedores con systemd 230 o anterior —de 2016— dejan de estar soportados. Si tienes distribuciones viejas dentro de LXC, revísalas antes de la ventana.
• /etc/sysctl.conf ya no se lee. Lo que tengas ahí hay que moverlo a /etc/sysctl.d/. Silencioso y fácil de pasar por alto.
• Los grupos de HA quedan obsoletos en favor de las reglas de HA, y se convierten automáticamente una vez todos los nodos están actualizados.
• Los thin pool de LVM pueden necesitar reparación manual con lvconvert --repair pve/data.

Cuándo no migrar en agosto

Montamos y mantenemos esta infraestructura, así que esto conviene leerlo con la ceja levantada: si hoy tienes tres nodos con Ceph y a la persona que los conoce de vacaciones, forzar la actualización en las dos semanas que quedan de mes es peor idea que llegar tarde.

Estar sin soporte no es lo mismo que estar comprometido. Es una probabilidad que empieza a subir, despacio, a partir del primer fallo que se publique y no se arregle en esa rama. Ese reloj corre en semanas. Una actualización de clúster mal ejecutada corre en minutos, y corre con las máquinas paradas.

Lo razonable en ese escenario es hacer en agosto todo lo que no requiere ventana —dejar los nodos en la última 8.4, subir Ceph a Squid, pasar pve8to9 --full y leerse la salida entera— y ejecutar la actualización en septiembre con todo el mundo de vuelta. Son unas semanas de exposición conocida y acotada a cambio de no reiniciar un nodo a ciegas. Si acabas en la 9, el siguiente paso es dejarla decente: eso lo escribimos en hardening de Proxmox 9.2 en producción.

Lo que no es una opción es dejarlo correr. El riesgo de esta fecha no está en septiembre: está en abril de 2027, con el nodo todavía en la rama 8, ocho meses de fallos del hipervisor sin cerrar, y apt sin haber dicho nada en todo ese tiempo porque Debian seguía cumpliendo su parte.

Al grano

Entra en un nodo y ejecuta dos órdenes. pveversion te dice en qué rama estás. pve8to9 --full te dice cuánto trabajo tienes por delante. Con esas dos salidas ya sabes si esto es una tarde de septiembre o un proyecto con presupuesto.

Y si el resultado es que estás en la 8 y todo parece ir bien: eso es exactamente lo que va a seguir pareciendo el mes que viene.

Fuentes (consultadas el 16 de agosto de 2026): la tabla de ciclo de vida con la fila de Proxmox VE 8 (primera versión 2023-06, Debian 12, fin de soporte de Debian 2026-07, fin de soporte de Proxmox VE 2026-08) y la cita «al menos mientras la versión de Debian correspondiente sea oldstable» salen del hilo Proxmox VE - Support Lifecycle, publicado por Martin Maurer; la FAQ de Proxmox VE recoge la política general con otra redacción («mientras la versión de Debian tenga soporte del equipo de seguridad de Debian, unos 3 años») y no contiene la tabla. Fin del soporte ordinario de Bookworm el 12 de julio de 2026, relevo del equipo de LTS y cobertura hasta el 30 de junio de 2028 — anuncio oficial de Debian. La descripción del LTS como «un simple traspaso de responsabilidad» sobre la misma infraestructura de réplicas, y debian-security-support / check-support-status — wiki de Debian, LTS/Using. Requisitos (pve-manager 8.4.1, Ceph Squid 19.2, 5 GB libres en la raíz), pve8to9, formato deb822 y la lista de problemas conocidos — guía oficial de actualización de 8 a 9. Versiones y novedades de la 9.2, las órdenes disarm-ha / arm-ha y la edición arm64 del 5 de agosto de 2026 — hoja de ruta de Proxmox VE. Que el kernel de Proxmox deriva del de Ubuntu — Proxmox VE Kernel. Proxmox publica el mes, no el día: la fecha «31 de agosto» que circula es el último día de ese mes, no un dato oficial.