Cómo actualizar Proxmox VE correctamente: del 8 al 9 y dentro de 9.x sin romper nada

Actualizar un hipervisor en producción da respeto, y hace bien en darlo. Una actualización mal planificada de Proxmox VE puede dejarte un nodo que no arranca, un clúster sin quórum o un Ceph a medias con las VMs paradas. La buena noticia es que Proxmox tiene un procedimiento de actualización muy bien engrasado, y si lo sigues al pie de la letra la probabilidad de romper algo es baja. La mala es que casi todos los sustos que he visto en clientes venían de saltarse pasos: no leer las notas, cambiar los repositorios a lo bruto, o querer subir de la 8 a la 9 sin pasar por el verificador.

En este tutorial vamos a ver dos escenarios distintos que la gente mezcla y no debería. Uno es la actualización menor dentro de la rama 9.x (por ejemplo de 9.1 a 9.2), que es rutina de mantenimiento. El otro es el salto mayor de la 8 a la 9, que por debajo es nada menos que una actualización de Debian 12 a Debian 13, y que exige método. Si vienes de instalar Proxmox hace poco, quizá te venga bien repasar antes cómo instalar Proxmox VE en un mini PC; y si aún no tienes copias de seguridad decentes, para el carro y monta primero un Proxmox Backup Server, porque lo vas a necesitar.

El modelo de versiones de Proxmox VE 9

Antes de tocar apt conviene tener claro qué hay debajo. Proxmox VE 9 se apoya en Debian 13 «Trixie». La rama arrancó con la 9.0 en verano de 2025, llegó la 9.1 el 19 de noviembre de 2025 y la 9.2 el 21 de mayo de 2026. El kernel pasó del 6.14 en la 9.0 al 7.0 como estándar en la 9.2, y ese detalle importa porque un cambio de kernel implica reinicio.

Los componentes de virtualización que trae la rama 9 son QEMU 11, LXC 7 y ZFS 2.4, con Ceph Squid 19.2 y Tentacle 20.2 en el lado del almacenamiento distribuido. En las versiones de la rama también han ido entrando cosas útiles para producción: balanceo dinámico de carga con el Cluster Resource Scheduler (CRS) según métricas en tiempo real, la posibilidad de desactivar y reactivar HA de forma segura para mantenimiento planificado, realms con OpenID Connect (OIDC) y mejoras de SDN con fabric OpenFabric/OSPF. No es solo un cambio de número: es una base de sistema operativo nueva.

La diferencia práctica entre los dos tipos de actualización es esta:

• Menor dentro de 9.x (9.0 → 9.1 → 9.2): mismo Debian por debajo, se resuelve con apt update && apt dist-upgrade. Rutina.
• Mayor 8 → 9: cambia el sistema operativo base (Debian 12 → 13). Exige el verificador pve8to9, cambiar los repositorios y una ventana de mantenimiento con reinicio. Método.

Los repositorios de Proxmox y el nuevo formato deb822

Todo el sistema de actualización vive en los repositorios APT. Proxmox ofrece tres, y elegir bien es lo primero que hay que hacer:

La suscripción de Proxmox se paga por socket físico ocupado y año, no por core, y todos los nodos de un clúster deben tener el mismo nivel. Los niveles van de Community (120 €) a Basic (370 €, 3 tickets/año), Standard (550 €, 10 tickets/año y soporte SSH remoto) y Premium (1100 €, tickets ilimitados y activación offline para entornos air-gapped). Que quede claro: Proxmox VE es software libre y gratuito. La suscripción te da acceso al repo enterprise y a soporte; no te da la funcionalidad, que la tienes toda con el repo no-subscription.

El aviso de suscripción y el error 401

Aquí está uno de los tropiezos más comunes. Una instalación recién hecha trae el repositorio enterprise activado por defecto pero sin una clave de suscripción válida. Resultado: en cuanto haces apt update, el servidor de Proxmox devuelve un 401 Unauthorized y la actualización falla. La solución no es ignorarlo: es desactivar el repo enterprise y activar el no-subscription si no tienes contrato, o meter tu clave si lo tienes.

El otro efecto visible es el banner de «No valid subscription» que salta al entrar en la interfaz web. Es un aviso, no un límite funcional. Con el repo no-subscription correctamente configurado, el sistema se actualiza perfectamente.

Dónde se configuran en Debian 13: el formato deb822

Este es un cambio que pilla a mucha gente desprevenida. En Debian 12 y Proxmox 8 los repos vivían en /etc/apt/sources.list y en ficheros .list con una línea por repo. En Debian 13 y Proxmox 9 se usa el nuevo formato deb822: cada repositorio es un fichero .sources dentro de /etc/apt/sources.list.d/, con campos legibles (Types, URIs, Suites, Components, Signed-By). Es más claro y más fácil de auditar, pero si esperabas editar el viejo sources.list te vas a encontrar con que ya no está el contenido ahí.

Los ficheros que te vas a encontrar en un Proxmox 9 son estos. El repositorio enterprise vive en /etc/apt/sources.list.d/pve-enterprise.sources:

# /etc/apt/sources.list.d/pve-enterprise.sources
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

El repositorio no-subscription vive en /etc/apt/sources.list.d/proxmox.sources. Si no tienes contrato, este es el que quieres activo (y el enterprise, comentado o eliminado):

# /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Fíjate en el campo Suites: trixie: ese es el nombre en clave de Debian 13, y es la pieza que cambia en el salto mayor. En un Proxmox 8 pondría bookworm. Los repositorios de Debian propiamente dichos (la base del sistema) están en /etc/apt/sources.list.d/debian.sources y también apuntan a trixie y trixie-updates. Para el repo de test, el componente es pvetest sobre la misma URI de descarga; solo lo activas en un banco de pruebas.

Todo esto se puede gestionar también desde la interfaz web, en Datacenter → Repositories, que te muestra qué repos hay, cuáles están activos y te avisa si tienes la combinación peligrosa de enterprise sin suscripción. Para producción, acostúmbrate a revisarlo ahí antes de cada actualización.

Copias de seguridad y plan de rollback antes de tocar nada

No hay actualización segura sin una salida de emergencia. Antes de escribir el primer apt update, ten resuelto el rollback. Esto no es opcional en producción.

• Backup de las VMs y contenedores en tu Proxmox Backup Server (o al menos vzdump a un almacenamiento externo). Verifica que los backups son recientes y restaurables; un backup que no has probado no es un backup.
• Copia de la configuración del clúster. El directorio /etc/pve es un sistema de ficheros replicado (pmxcfs) con toda la configuración: definiciones de VMs, storage, red, usuarios. Haz una copia fuera del nodo.
• Snapshot del sistema si el disco raíz está sobre ZFS. Un zfs snapshot del rpool/ROOT te permite volver atrás el sistema operativo si el dist-upgrade se tuerce. Si es una VM anidada, un snapshot del hipervisor de abajo.

Un backup mínimo de la configuración y un snapshot ZFS del sistema se hacen así:

# Copia del árbol de configuración del clúster/nodo
tar czf /root/etc-pve-$(date +%F).tar.gz /etc/pve /etc/network/interfaces /etc/apt

# Snapshot del sistema raíz sobre ZFS (ajusta el nombre del dataset a tu instalación)
zfs snapshot rpool/ROOT/pve-1@antes-upgrade-9

# Comprobar que el snapshot existe
zfs list -t snapshot rpool/ROOT/pve-1

El plan de rollback para el salto mayor tiene un matiz honesto que hay que decir claro: una vez que has hecho el dist-upgrade de Debian 12 a 13, no hay marcha atrás limpia por APT. El «volver» consiste en restaurar el snapshot del sistema o reinstalar el nodo y recuperar VMs desde el backup. Por eso el verificador previo importa tanto: la idea es no llegar a necesitar el rollback.

Actualizaciones menores dentro de 9.x

Empecemos por lo fácil, que es lo que harás casi cada mes. Subir de una versión menor a otra dentro de la rama 9 (9.0 → 9.1 → 9.2, o simplemente aplicar parches de seguridad) es el flujo estándar de Debian y consta de dos comandos:

apt update
apt dist-upgrade

Usa dist-upgrade (o apt full-upgrade, es equivalente), no apt upgrade a secas. La diferencia es que dist-upgrade sí instala paquetes nuevos y retira los obsoletos cuando las dependencias lo requieren, algo que Proxmox necesita constantemente porque sus metapaquetes tiran de dependencias que cambian entre versiones. Con apt upgrade te arriesgas a dejar paquetes retenidos a medias.

Antes de lanzarlo, dos hábitos que ahorran disgustos:

1. Lee las notas de la versión. Cada versión menor tiene su changelog y, a veces, avisos concretos (un cambio de comportamiento en SDN, en HA o en el storage). Dos minutos de lectura evitan sorpresas.
2. Mira si cambia el kernel. Si el dist-upgrade instala un kernel nuevo —cosa habitual, sobre todo en el salto a la 9.2 con el kernel 7.0—, tienes que reiniciar para arrancar con él. Hasta que no reinicies estarás corriendo el kernel viejo aunque el paquete nuevo ya esté instalado.

Comprueba si hay kernel nuevo pendiente de arrancar comparando el que corre con el instalado:

# Kernel en ejecución ahora mismo
uname -r

# Kernels instalados y cuál arrancará por defecto
proxmox-boot-tool kernel list

En un nodo suelto, reinicias en tu ventana de mantenimiento y listo. En un clúster, aunque sea una actualización menor, sigue aplicando la regla de oro: un nodo cada vez, nunca todos a la vez. Lo vemos en detalle más abajo.

El salto mayor: de Proxmox VE 8 a 9

Aquí es donde hay que ser metódico. Recuerda que por debajo estás actualizando Debian 12 «Bookworm» a Debian 13 «Trixie», con cambio de kernel, de bibliotecas de sistema y de formato de repositorios. El proceso oficial tiene siete pasos y conviene no saltarse ninguno.

Paso 1: llegar a la última 8.x

El salto 8 → 9 solo está soportado desde la última versión de la rama 8. Antes de nada, actualiza dentro de la 8 hasta el final:

apt update
apt dist-upgrade
pveversion   # confirma que estás en la última 8.x antes de seguir

Reinicia si esa actualización trajo un kernel nuevo. Quieres partir de un sistema 8 limpio, al día y arrancado con su kernel definitivo antes de empezar el salto.

Paso 2: ejecutar pve8to9 --full

Este es el paso que no te puedes saltar. Proxmox incluye un script que audita el sistema y te dice, antes de tocar nada, qué problemas vas a encontrar. Lánzalo con la opción --full para que haga todas las comprobaciones:

pve8to9 --full

El script revisa decenas de cosas: estado del clúster y quórum, versiones de paquetes, configuración de repositorios, espacio en disco, estado de Ceph si lo hay, opciones de red obsoletas, montajes, servicios en marcha. Devuelve resultados clasificados en PASS (bien), WARN (revisar) y FAIL (bloqueante). Ejecútalo en cada nodo del clúster, no solo en uno.

Paso 3: resolver todos los avisos

Un FAIL es innegociable: si lo dejas, la actualización se rompe. Un WARN normalmente pide una decisión consciente. La regla es sencilla: no cambies los repositorios a la 9 hasta que pve8to9 salga limpio de FAIL. Corrige lo que marque, vuelve a lanzar pve8to9 --full y repite hasta que estés satisfecho con el resultado. El script está pensado precisamente para ejecutarse varias veces: antes, durante y después.

Paso 4: cambiar los repositorios a trixie/9

Ahora sí, apuntamos los repos a Debian 13. Esto significa cambiar la suite de bookworm a trixie tanto en los repos de Debian como en los de Proxmox, y —si no tienes suscripción— asegurarte de que el enterprise está desactivado y el no-subscription activo. En el formato deb822, el fichero no-subscription queda así:

# /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Y el fichero de Debian base, /etc/apt/sources.list.d/debian.sources, debe apuntar también a trixie y trixie-updates. Con los repos cambiados, refresca el índice de paquetes:

apt update

Si aquí te salta un 401 Unauthorized, es que el repo enterprise sigue activo sin suscripción: desactívalo antes de continuar. Un apt update limpio es el semáforo verde para el siguiente paso.

Paso 5: apt dist-upgrade

El momento de la verdad. Lanza la actualización completa del sistema:

apt dist-upgrade

Va a descargar cientos de paquetes y a hacerte preguntas por el camino. Durante el proceso, APT te preguntará qué hacer con ficheros de configuración modificados (los típicos *.dpkg-dist). Regla general para ficheros de Proxmox y del sistema: en la duda, mantén tu versión y revisa las diferencias después, salvo que sepas que un fichero concreto debe adoptar la versión del mantenedor. No cierres la sesión SSH ni cortes la energía a mitad; si te preocupa perder la conexión, lánzalo dentro de tmux o screen.

Paso 6: reiniciar

Cuando el dist-upgrade termina, reinicia el nodo aunque tengas la sensación de que «ya estaba en el 6.14». El kernel de la 9 se ha recompilado con el compilador y la ABI de Proxmox VE 9, así que arrancar con el kernel nuevo es obligatorio para que todo (módulos, QEMU, ZFS) quede coherente:

reboot

Por esto mismo el salto 8 → 9 se hace siempre en ventana de mantenimiento: hay un reinicio garantizado por medio.

Paso 7: verificar

El nodo vuelve. Antes de cantar victoria, comprueba que de verdad está en la 9 y que todo funciona. Lo detallamos en la sección de verificación, pero el mínimo es volver a pasar el script, ahora en modo post-upgrade:

pve8to9 --full
pveversion -v

Actualizar en clúster sin perder quórum

Un clúster de Proxmox mantiene la coherencia mediante quórum: necesita que la mayoría de los nodos estén vivos y de acuerdo. Si actualizas a lo loco y tumbas varios nodos a la vez, pierdes quórum y el /etc/pve se vuelve de solo lectura, con lo que no puedes ni arrancar VMs ni tocar configuración. La disciplina en clúster es la parte más delicada de todo esto.

La estrategia es nodo a nodo, uno cada vez, manteniendo siempre el quórum. El orden que sigo:

1. Confirma el estado del clúster antes de empezar. Todos los nodos deben verse y el quórum estar establecido:

   pvecm status

2. Vacía el nodo que vas a actualizar. Migra sus VMs y contenedores a otros nodos (migración en vivo si el storage lo permite), o si usas HA deja que las reubique. La idea es que el nodo quede sin cargas antes de reiniciarlo. Si tienes HA, puedes desactivarlo de forma segura para el mantenimiento planificado y reactivarlo después.
3. Actualiza ese nodo solo: los pasos del salto 8 → 9 (o el dist-upgrade menor) sobre ese nodo, con su reinicio.
4. Verifica que el nodo ha vuelto sano y en la versión nueva, que se ha reincorporado al clúster y que el quórum sigue en pie. Solo entonces pasas al siguiente.
5. Repite nodo por nodo, devolviendo o rebalanceando las cargas según avanzas.

Dos advertencias que valen su peso en oro. Primera: no mezcles versiones más tiempo del imprescindible. Durante el salto 8 → 9 el clúster convive temporalmente con nodos en 8 y nodos en 9, y eso está soportado como estado transitorio, pero no como estado permanente. Termina el salto de todos los nodos en la misma ventana o en ventanas seguidas. Segunda: vigila que nunca caiga el quórum. En un clúster de tres nodos solo puedes tener uno caído a la vez; con dos caídos pierdes la mayoría. Si tienes dispositivo de QDevice para desempate, tenlo en cuenta en la cuenta de la mayoría.

Ceph se actualiza aparte

Si tu clúster usa Ceph hiperconvergente, hay una regla que no se negocia: el salto de PVE y el salto de Ceph son dos procesos distintos y se hacen por separado. No los mezcles en la misma tanda de comandos. Ceph tiene su propio orden de actualización de componentes —monitores primero, luego managers, luego OSDs, y con cuidado con los flags que evitan el rebalanceo durante la ventana— y su propia documentación de versión a versión (Squid 19.2, Tentacle 20.2 en la rama 9).

La secuencia sensata cuando hay Ceph es: primero completas el salto de Proxmox VE a la 9 en todos los nodos siguiendo el proceso de arriba, y después, con el clúster ya en 9 y estable, abordas la actualización de Ceph siguiendo su guía específica de esa transición. Mientras Ceph esté a medias, mantén los OSDs arriba y no fuerces reequilibrados. El pve8to9 --full ya te avisa del estado de Ceph, hazle caso. Intentar actualizar las dos cosas de golpe es la receta más rápida para un clúster de almacenamiento degradado con las VMs sufriendo.

Verificación post-upgrade

Una actualización no termina cuando el nodo reinicia, sino cuando has comprobado que todo está en su sitio. Esta es mi lista de verificación después de cada salto:

Versión y componentes. Confirma que el nodo está en la 9 y qué versiones exactas de kernel, QEMU, LXC, ZFS y demás corren:

pveversion -v

Este comando lista el metapaquete proxmox-ve y todos sus componentes con su versión. Es lo primero que miro para saber que el salto ha cuajado de verdad y no me he quedado con paquetes retenidos.

Clúster y quórum. Que el nodo se ve con el resto y que hay mayoría:

pvecm status

Máquinas virtuales y contenedores. Que arrancan, que la red interna les responde y que los servicios de dentro están vivos. Revisa el estado general y arranca alguna VM de prueba:

qm list        # estado de las VMs
pct list       # estado de los contenedores LXC

Red. Que los bridges, VLANs y —si usas SDN— las zonas están operativos, y que el tráfico externo entra y sale. Un ip a y un par de ping desde una VM a Internet y hacia otra VM del clúster cubren lo básico.

Verificador post-upgrade. Vuelve a pasar pve8to9 --full: en modo posterior te confirma que no quedan cabos sueltos de la migración.

Los errores típicos que te vas a ahorrar

Casi todos los desastres que he tenido que rescatar caben en esta lista corta:

• Saltarse pve8to9. Es el error número uno. El script existe precisamente para que no te lleves sorpresas; ignorarlo es actualizar a ciegas.
• Repos mal configurados. El enterprise activo sin suscripción da 401 y bloquea el apt update. Y olvidar cambiar la suite a trixie en todos los ficheros .sources (incluido el de Debian base) deja el salto a medias.
• No reiniciar tras cambio de kernel. Te quedas corriendo el kernel viejo con módulos nuevos. Reinicia siempre que cambie el kernel, y hazlo en ventana de mantenimiento.
• Actualizar todos los nodos a la vez. Pierdes quórum y el clúster se te queda en solo lectura. Uno cada vez, sin excepción.
• Mezclar el salto de Ceph con el de PVE. Dos procesos, dos ventanas, dos guías. Nunca a la vez.
• No tener rollback. Backups sin probar, sin snapshot del sistema, sin copia de /etc/pve. Cuando algo se tuerce en el dist-upgrade mayor, esa red de seguridad es la diferencia entre una hora de susto y un fin de semana reinstalando.

Con método, el salto de Proxmox VE 8 a 9 es aburrido, que es exactamente lo que quieres de una actualización de hipervisor en producción. Lee las notas, pasa el verificador, respeta el quórum y ten preparada la vuelta atrás. Lo demás es teclear los comandos en el orden correcto.