El salto de Proxmox 8 a 9 fue tan fluido que la gente dudó de su propia ansiedad
Las grandes actualizaciones de infraestructura suelen venir con un pequeño ritual de temor. Las copias de seguridad se revisan dos veces, las notas de la versión se miran como si fueran documentos legales y cada administrador se imagina en secreto ese servicio maldito que no va a volver. Por eso los elogios a la actualización de Proxmox VE 8 a 9 llamaron tanto la atención. El dueño de un servidor doméstico actualizó in situ de PVE 8.4.19 a 9.2.3, ejecutó pve8to9 --full, siguió la wiki, cambió los repositorios, hizo el dist-upgrade, reinició y obtuvo exactamente lo que quiere cualquier administrador: nada de dramas, nada de sorpresas, nada de excavaciones arqueológicas entre paquetes rotos. Después compró una suscripción Community, porque un acabado así no se mantiene solo.
La herramienta de comprobación fue la verdadera protagonista
La estrella del hilo fue el comprobador de actualización más que cualquier función nueva y reluciente. El autor original dijo que pve8to9 --full detectó todo lo importante antes de que la actualización empezara siquiera. Es el tipo de herramienta que la gente subestima hasta que la salva de sí misma. Un salto de versión mayor da miedo porque las incógnitas están por todas partes: repositorios, gestores de arranque, contenedores, piezas de kernel personalizadas, almacenamiento, tarjetas de red, decisiones de configuración antiguas que olvidaste haber tomado hace tres años. Una buena lista de comprobación convierte el peligro invisible en una lista de tareas.
Varias personas compartieron esa confianza. Un comentarista dijo que su propia actualización fue sin contratiempos pese a ser "un inútil con Unix/Linux/etc", y añadió que el script de 8 a 9 te dice qué va a reventar para que lo arregles con calma. Otro actualizó unos nueve nodos, incluido un clúster de siete nodos, y dijo que casi todos fueron sin problemas. La única excepción fue un error del usuario y no de Proxmox, e incluso ese nodo sobrevivió tras algo de trabajo extra. No hay magia en eso; así es como se nota tener buenas barreras de protección.
Los montajes sencillos lo tuvieron más fácil
La publicación original tuvo cuidado de no exagerar la experiencia. Su montaje era básico: un nodo independiente, sin Ceph, sin clúster y casi sin personalización. Admitió abiertamente que la sencillez hizo gran parte del trabajo y que esperar a que 9.x madurara probablemente ayudó. Esa honestidad importaba porque impedía que el elogio se convirtiera en "todo el mundo debería darle a actualizar ya mismo y dejar de preocuparse". Un host estándar es el carril fácil, y que el carril fácil funcionara limpiamente sigue mereciendo una celebración.
Los comentarios lo dejaron claro. Algunos usuarios se quedaron lo bastante tranquilos como para replantearse sus plazos de actualización. Una persona lo había ido aplazando porque, según su experiencia, cada cambio importante rompe alrededor del 10 por ciento de las cosas. Tampoco tenía nada demasiado complicado, pero si se rompía el 10 por ciento equivocado, reconstruir podía llevar tiempo de verdad. Tras leer la historia de éxito, se planteó pasar la actualización de "proyecto para las vacaciones de verano" a "proyecto para un fin de semana largo". Un informe de éxito aburrido puede hacer eso: da a la gente nerviosa un suelo en el que apoyarse.
Luego hablaron los montajes más desordenados
La otra cara del hilo fue directa: el "mi montaje es bastante básico" estaba haciendo mucho trabajo. Un comentarista dijo que su actualización fue de todo menos fluida. Pasó casi un día persiguiendo errores antes y después de la instalación, sufrió un kernel panic al arrancar y acabó borrando el host y restaurando desde las copias de seguridad. Se lo tomó con elegancia, diciendo que no era el fin del mundo y que se alegraba de que al autor original le hubiera ido bien, pero el aviso estaba claro: las actualizaciones fluidas no se reparten por igual.
Otro usuario también sufrió un kernel panic en dos de tres instancias y tuvo que modificar algunos ajustes relacionados con GRUB antes de que todo se asentara. Alguien más tenía un sistema más complejo, con módulos de kernel i915 y xe personalizados, passthrough de HDD y NVMe por ID y otros trabajos a medida. Su actualización no fue tan fácil, pero aun así fue mejor de lo esperado porque la herramienta le señaló muchas cosas que arreglar primero. Ese es el punto medio más realista, en el que Proxmox hizo su trabajo y las rarezas locales también tuvieron algo que decir.
Los contenedores y los apaños fueron la prueba de fuego
LXC resultó ser una línea divisoria. El autor original solo tenía un contenedor de Pi-hole, y pasó la actualización sin necesidad de cambiar la configuración. Tras el reinicio arrancó con normalidad y el DNS siguió resolviendo. Incluso volvió a ejecutar pve8to9 --full después y vio un aviso de que no se podía obtener el estado de soporte de cgroup del contenedor porque el script no lograba construir la ruta al binario de systemd. Su lectura fue que parecía un aviso cosmético conocido del comprobador en PVE 9, no un problema real del contenedor.
Otro comentarista tenía una historia de contenedores mucho más fea. Dijo que la actualización del sistema operativo en sí fue fluida, pero que después se rompió un montón de apaños de un administrador anterior para Docker y FreeIPA dentro de LXC. Esos apaños incluían cosas como desactivar AppArmor de forma agresiva, y la herramienta de actualización no detectó la mayor parte. Su conclusión fue sencilla: pensaba pasar pronto ese montaje a VMs. Es una lección útil, porque las herramientas de actualización pueden detectar problemas a nivel de plataforma, pero no siempre entienden años de decisiones del tipo "que funcione como sea" apiladas dentro de un contenedor.
Los gremlins de red esperaron unos días
No todos los problemas aparecieron de inmediato. Un usuario actualizó un clúster de cinco nodos, nodo a nodo, de 8.4 a 9.2.3, y al principio todo parecía ir bien. Luego, al cabo de un par de días, algunos nodos empezaron a perder la conectividad LAN, con registros llenos de errores de red. Su arreglo rápido fue desactivar el procesamiento en la tarjeta de red y pasarlo a la CPU. Ese tipo de fallo diferido es el motivo por el que los administradores con experiencia no se relajan del todo tras el primer reinicio correcto.
También explica por qué la gente no dejaba de remitir a la documentación oficial y a los problemas conocidos de la actualización. En el hilo apareció un enlace a la guía de actualización, seguido de un recordatorio de leerlo todo, sobre todo la sección de problemas conocidos. Puede sonar obvio, pero es el consejo que la gente se salta cuando se cree con suerte. El camino exitoso aquí nunca fue un dist-upgrade a lo loco. Fue copias de seguridad, lista de comprobación, documentación, cambio de repositorios, actualización, reinicio, verificación y luego seguir vigilando: pasos aburridos, y muy buenos.
Apoyar el proyecto pasó a formar parte de la historia
El último gesto del autor original le dio al hilo su toque emotivo: tras la actualización sin problemas, compró una suscripción Community de un año. Es más que un guiño de fan. Reconoce que unas rutas de actualización maduras, una documentación detallada y unas herramientas de comprobación previa cuestan trabajo. No aparecen porque unos duendes de la infraestructura se aburrieran. Se mantienen, se prueban, se discuten y se mejoran hasta que un salto de versión que da miedo resulta rutinario para un usuario normal con un servidor normal.
Ese mensaje llegó junto a otra historia de migración: un comentarista acababa de instalar su primer Proxmox VE tras dejar Microsoft Hyper-V y ya le estaba gustando. Ese es el contexto más amplio. Proxmox ya sirve a mucha más gente que los veteranos del homelab. Está atrayendo a quienes abandonan otras plataformas, a quienes montan clústeres, a quienes ejecutan contenedores llenos de parches, a quienes tienen kernels personalizados y a quienes piden ayuda a Gemini o a Claude cuando el arranque se tuerce. La ruta de actualización tiene que atenderlos a todos de una forma cercana a la realidad.
Fluido no significa descuidado
La mejor conclusión del hilo es que Proxmox consiguió que una actualización seria resultara manejable para mucha gente, lo cual es distinto de decir que pasar de Proxmox 8 a 9 no tiene riesgos. Para nodos independientes sencillos, el camino puede ser casi aburrido. Para clústeres, todavía puede ser limpio si sigues la documentación. Para hosts personalizados, apaños antiguos, passthrough, módulos a medida y contenedores frágiles, la actualización todavía puede morder. No hay contradicción en eso; así es la infraestructura.
Así que el ánimo adecuado es un optimismo prudente. Ejecuta pve8to9 --full. Lee la guía de actualización y los problemas conocidos, haz copia de seguridad de los invitados y de la configuración del host, y ten claro cómo te recuperarás si el gestor de arranque se pone raro. No des por hecho que un contenedor lleno de apaños se comportará como una VM limpia. Vigila el sistema durante días, no minutos. Y cuando una actualización tan grande sale bien, quizá conviene dar las gracias con algo más que un comentario. Los saltos de versión nunca van a dejar de dar miedo, y es impresionante que la buena ingeniería consiga que parezcan casi un trámite.