Proxmox VE 9.0 vs 8.4: migración, novedades y cuándo actualizarte

septiembre 4, 2026 Alfonso Moreno | Sysadmin Senior 82 Visitas 9 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 4-6 horas para setup completo.
Requisitos: CPU con VT-x, 16+ GB RAM, 64+ GB SSD.
Resultado: Homelab con VMs/LXC, backups PBS, monitoring integrado.
Troubleshooting: Logs de Proxmox, snapshots, restore drills mensuales.

Proxmox VE 9.0 existe, 8.4 sigue vivo hasta agosto 2026: el upgrade es gradual

Si administras un cluster Proxmox, en algún momento entre agosto 2025 y agosto 2026 te toca decidir si te quedás en la rama 8.4 (soportada hasta agosto 2026) o saltás a 9.0 (released agosto 2025, base Debian 13 Trixie, kernel 6.14.8). En septiembre 2026 estamos en el último tercio de la ventana de overlap de 12 meses que Proxmox diseñó para que nadie tuviera que migrar el mismo día que sale el nuevo major. Esta guía es para ayudarte a decidir cuándo, no si, te movés a 9.x.

Todo verificado contra el press release oficial de Proxmox del 5 de agosto de 2025, los release notes de 9.1 del 19 de noviembre de 2025 y la wiki de upgrade de la comunidad. Lo que importa para tu decisión:

El estado real de 8.4 vs 9.0 en septiembre 2026

Lo primero que hay que entender es que esto NO es un fork. 8.4 no es “la versión vieja y abandonada”; es una rama LTS que recibe security updates y bug fixes críticos hasta agosto 2026, un año completo después del release de 9.0. Proxmox hizo esto específicamente para que operadores con SLAs estrictos pudieran planificar la migración sin presión.

El calendario práctico:

Proxmox VE 8.4: support general hasta agosto 2026. Bug fixes críticos y CVEs hasta esa fecha. Después de eso, no más updates — sigue funcionando pero te quedás sin parches.
Proxmox VE 9.0: released 5 de agosto de 2025, base Debian 13 Trixie, kernel 6.14.8-2, QEMU 10.0.2, LXC 6.0.4, Ceph Squid 19.2.3, ZFS 2.3.3.
Proxmox VE 9.1: released 19 de noviembre de 2025, primeros bug fixes de la rama 9.x. Esta es la versión recomendada para producción hoy.

El overlap entre ramas es ~12 meses (8.4 EOL agosto 2026, 9.0 release agosto 2025). Eso significa que si instalas 9.0/9.1 hoy y te va mal, puedes volver a 8.4 dentro del año de soporte y tener parches de seguridad mientras resolvés el problema.

Qué cambia realmente cuando saltás de 8.4 a 9.x

9.x no es “8.4 con mejor UI”. Hay cambios de fondo que importan para tu decisión:

1. Base Debian 13 Trixie (en lugar de 12 Bookworm)

Todo el sistema operativo base se mueve a Trixie. Esto significa:

Nuevo kernel (6.14.8-2 estable default en 9.0; con 9.1 puede haber un kernel posterior)
Versiones más nuevas de paquetes core (glibc, OpenSSL, systemd)
Cambios sutiles en defaults de red, sysctl, mounts

Si tienes scripts que asumen paths de Debian 12, van a requerir ajustes. Si usas paquetes oficiales Debian, tienes que validar que la versión en Trixie sea compatible con tu stack (Python, Node, Postgres, lo que uses).

2. Snapshots para LVM thick-provisioned shared storage

Esta es la feature más esperada para deployments enterprise con SAN. Antes, si tenías almacenamiento compartido sobre iSCSI o FC con LVM thick-provisioned, no podías sacar snapshots a nivel Proxmox — tenías que apoyarte en features del storage vendor. Desde 9.0, Proxmox implementa snapshots como volume chains (un snapshot es un volume que registra solo diferencias con su parent), igual que ya hacía con qcow2 para almacenamiento local.

Impacto práctico: si venís de VSAN, NetApp, Pure Storage o cualquier SAN que NO tenía snapshot nativo, ahora puedes manejar todo desde Proxmox sin integrar el storage vendor. Para clusters de menos de 50 VMs sigue siendo más simple usar qcow2 en NFS; para SAN enterprise grandes, esta feature es la diferencia entre mantener una integración con el vendor y no hacerlo.

3. SDN Fabrics (OpenFabric + OSPF)

El SDN (Software-Defined Networking) de Proxmox era funcional pero limitado a topologías simples. 9.0 introduce Fabrics, que permite construir arquitecturas spine-leaf de 2 capas con redundancia de NICs y failover automático. Soporta dos protocolos de routing dinámicos: OpenFabric (más simple, suficiente para la mayoría) y OSPF (más rico, compatible con infra enterprise existente).

Si tu cluster es chico (3-5 nodos), no vas a notar el cambio — el SDN simple sigue funcionando igual. Si tienes 10+ nodos y quieres EVPN underlay o Ceph full-mesh, Fabrics te ahorra meses de configuración manual.

4. HA Affinity Rules

Antes, las reglas HA en Proxmox eran binarias: VM “con affinity” o VM “sin affinity”. 9.0 introduce reglas granulares: puedes decir “esta VM con base de datos corre en el mismo nodo que su app server” o “estas 3 réplicas de un servicio corren en nodos diferentes”. Para apps con dependencias internas y latencia crítica entre tiers, esto resuelve problemas reales.

5. Mobile interface rewrite (Yew/Rust)

La interfaz móvil se rehíció completa con Yew (framework Rust para WASM). Más rápida, mejor UX. Si gestionas tu cluster desde el celular en alguna emergencia, vale la pena.

6. ZFS 2.3.3 con adding devices a RAIDZ

Antes, si querías agregar un disco a un RAIDZ pool existente, la única opción era destruir y recrear el pool (con el downtime correspondiente). 2.3.3 permite agregar devices a RAIDZ pools existentes con downtime mínimo. Si usas ZFS, esta es la feature que justifica el upgrade por sí sola.

Cómo hacer el upgrade real (paso a paso)

El upgrade oficial está documentado en pve.proxmox.com/wiki/Upgrade_from_8_to_9. Resumen con los puntos donde la gente se traba:

# 1. Backup completo ANTES de tocar nada. Sin excusas.
# - vzdump de todas las VMs
# - Snapshot de la config /etc/pve (es DB-backed pero por las dudas)
# - Si tienes Ceph, snapshot del CephFS y RBD pools
pvebackup
# 2. Validar que no hay subscriptions activas de enterprise repo
# (algunos repos viejos se rompen con Trixie)
pve7to8 --full  # este sí corre en 8.4 y verifica compat
# Si tienes subscripción enterprise, asegurate de que tu key es válida
# 3. Actualizar paquetes actuales de 8.4 al último patch
apt update && apt dist-upgrade -y
# IMPORTANTE: reiniciar si actualizó kernel
reboot
# 4. Cambiar repositorios de Bookworm a Trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-install-repo.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
apt update
# 5. Upgrade mayor
apt dist-upgrade -y
# Esto toca pve-manager, qemu-server, todos los paquetes core.
# Tiempo esperado: 15-30 minutos, dependiendo de la velocidad de disco.
# 6. Verificar que el cluster levantó
systemctl status pveproxy pvedaemon
pvecm status  # debe mostrar todos los nodos
# 7. Reactivar Ceph (si lo usas)
pveceph install  # solo si quieres añadir nodos Ceph nuevos
# Para upgrade de Ceph Reef → Squid, seguí:
# https://pve.proxmox.com/wiki/Ceph_Reef_to_Squid

El punto 1 NO es opcional. La wiki oficial dice explícitamente “plan the upgrade carefully, make and verify backups before beginning”. Si tienes VMs críticas, prueba el upgrade primero en un nodo de prueba con VMs idénticas (no en producción directa).

Errores comunes que vale anticipar

Repos rotos después del upgrade: si tienes scripts que asumen paquetes de Debian 12 que ya no existen en 13, fallan. La comunidad tiene una lista curada de paquetes problemáticos.
Drivers de red viejos: el kernel 6.14 de 9.0+ tiene drivers más nuevos, pero también removió compatibilidad con hardware de red muy viejo (NICs de 1GbE con chipsets Realtek antiguos). Si tu cluster corre sobre hardware reciclado con NICs non-server-grade, validá antes.
Ceph Reef → Squid: si usas Ceph Hyperconverged, el upgrade de Proxmox NO upgradea Ceph automáticamente. tienes que hacerlo manualmente siguiendo la wiki Ceph Reef to Squid, y eso tiene downtime planeado.
VM con drivers virtio viejos: VMs que vienen de Proxmox 7.x con kernel custom pueden tener problemas con los drivers virtio nuevos. Actualizá kernel de las VMs antes del upgrade del host.

El test que vale la pena antes de producción

Si tienes un cluster chico (3-5 nodos) y quieres migrar de 8.4 a 9.1, el workflow que recomiendo:

Día 0: backup completo verificado de TODO. Probar restaurar un backup de una VM random en otro host, confirmar que funciona.
Día 1: upgrade de UN solo nodo en el cluster (Proxmox permite cluster rolling upgrade si todos los nodos son 8.x). Mantener los otros nodos en 8.4.
Día 1-3: migración de VMs live de otros nodos al nodo upgraded. Observar comportamiento por 48 horas.
Día 4: si todo bien, upgrade del segundo nodo.
Día 7: si todo bien, upgrade del tercero, etc.

Si algo falla en cualquier paso, puedes volver a 8.4 ese nodo (downgrade documentado en la wiki). El cluster sigue funcionando con nodos en versiones mixtas mientras dure el overlap de 12 meses.

Cuándo NO migrar (todavía)

Hay tres razones legítimas para quedarse en 8.4:

Hardware con drivers solo en kernel viejo: si tienes storage arrays o NICs que requieren drivers DKMS de kernels viejos que no compilan en 6.14, espera.
Ceph Reef en producción crítica: si tu cluster corre Ceph Reef y migrar a Squid requiere downtime planeado que no puedes coordinar antes de agosto 2026, espera al último momento.
Stack de software enterprise con dependencias pinneadas: si tu ERP o base de datos critical está certificada en una versión específica de glibc o systemd y aún no tienes validación en Trixie, espera.

Si ninguna de esas aplica (cluster pequeño-mediano, hardware moderno, stack de software que se actualiza), el upgrade es straightforward y la documentación oficial es suficiente.

Resumen ejecutivo

Cluster nuevo en 2026: instala Proxmox VE 9.1 directamente, no tiene sentido empezar con 8.4.
Cluster 8.4 funcionando bien y sin presión de fechas: actualizá en los próximos 3-6 meses, no hay urgencia pero tampoco hay razón para esperar.
Cluster 8.4 con Ceph Reef: coordiná primero el upgrade Ceph Reef → Squid, después Proxmox 8.4 → 9.x.
Cluster 8.4 con hardware viejo (NICs Realtek, storage legacy): prueba primero en un nodo, validá drivers, después upgrade progresivo.
Cluster 7.x o anterior: primero upgrade a 8.4 LTS, espera 1-2 meses de estabilización, después upgrade a 9.x.

El upgrade es trabajo de una tarde bien planificada, no un proyecto de semanas. Lo importante es el backup verificado y el orden correcto de los pasos.

Preguntas frecuentes

¿Por qué Proxmox VE 9.0 vs 8.4: migración, novedades y cuándo actualizarte es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Proxmox VE 9.0 vs 8.4:?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Proxmox VE 9.0 vs 8.4:?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Proxmox VE 9.0 vs 8.4: y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Proxmox VE 9.0 vs 8.4:?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.