Actualizar Proxmox 8.2.7 a 9.2 en seis nodos y un servidor de backup

La pregunta que se hace todo administrador prudente antes de pulsar el botón

La publicación era sencilla, pero cargaba justo con el peso que hace incómodas las actualizaciones de infraestructura: ¿puedo actualizar directamente de Proxmox 8.2.7 a 9.2, y debería hacerlo? A quien preguntaba no le interesaba saber si podía pulsar el botón o si apt lo permitiría técnicamente. Quería saber si era sensato coger un entorno de seis nodos, sacar todas las VM de una máquina, actualizar ese nodo, repetir hasta tener todo el clúster en 9.2 y, cuando los hipervisores estuvieran listos, actualizar el Proxmox Backup Server.

Son los nervios que tocan, y no tienen nada de imprudentes. Actualizar un homelab de un solo nodo es una cosa; un entorno de seis máquinas es otra historia. Aunque no sea un centro de datos corporativo gigante, tiene su ritmo, sus dependencias y sus consecuencias. Las VM tienen que ir a algún sitio, el clúster tiene que seguir sano, el almacenamiento y la red tienen que seguir comportándose y el servidor de backup tiene que seguir siendo de fiar. Detrás de todo eso está el hecho incómodo de que una actualización de versión mayor casi nunca es solo una actualización de versión. También arrastra Debian, el kernel, QEMU, los tipos de máquina, los repositorios, las comprobaciones de paquetes y cualquier configuración local extraña que lleve años funcionando sin quejarse.

La respuesta del hilo fue casi aburrida: actualiza primero a la última Proxmox 8, probablemente la 8.4, y después sigue al pie de la letra la guía oficial de actualización de 8 a 9. Es el tono que los administradores deberían amar y odiar a la vez, sin drama, sin atajos y sin frase mágica. Lee la guía, ejecuta el comprobador, corrige lo que señale, vuelve a ejecutarlo y avanza solo cuando la máquina esté lo bastante limpia como para fiarte de ella.

"Primero a la última 8" se convirtió en el consenso práctico

El consejo más contundente fue no tratar la 8.2.7 como la plataforma de lanzamiento perfecta. Varias personas insistieron en la misma idea: pasar primero a la última versión 8.x y migrar desde ahí a la última 9.x. Una respuesta cortó de raíz la ansiedad con las versiones al explicar que, cuando pasas a la siguiente versión mayor, en realidad no eliges aterrizar en una vieja 9.0. Recibes la versión 9 actual. Así que sí, en la práctica el destino es la 9.2, pero el camino más limpio empieza por poner en orden la rama 8 actual.

Ese consejo importa porque las versiones intermedias suelen traer ayudas para la actualización, correcciones de compatibilidad, avisos y un comportamiento de los repositorios que las versiones menores más antiguas no tienen. Se trata de reducir incógnitas. Si el camino documentado espera que estés en la última 8.x antes de cruzar a la 9.x, saltar desde un host con una 8.2.7 más antigua solo añade misterio sin ninguna recompensa. Cuanto más aburrido sea el punto de partida, menos emocionantes serán los fallos.

Un usuario resumió la versión adulta del plan: sigue la guía de actualización al pie de la letra, no a grandes rasgos. Ejecuta la comprobación, corrige los mensajes, vuelve a ejecutarla y sigue así hasta que los avisos y los errores estén resueltos o claramente entendidos. Contó que había actualizado 10 servidores sin ningún problema que no se hubiera provocado él mismo. Esa última frase es la que hay que pegar encima del rack. Las actualizaciones mayores no necesitan ayuda para ser arriesgadas, así que el objetivo es eliminar cada herida autoinfligida antes de que apt se acerque siquiera al punto de no retorno.

El enlace a la guía fue a la vez respuesta y prueba de actitud

La respuesta directa más votada fue simplemente un enlace a la guía de actualización de Proxmox de 8 a 9. Otra persona respondió: "Es todo lo que necesitas. Hilo cerrado". Suena brusco, pero también refleja cómo funciona la cultura de la infraestructura. Nadie quiere reescribir el manual en un hilo de comentarios cuando el manual existe por algo. Para una actualización mayor de un hipervisor, la guía es el mapa.

Luego llegó la tensión de siempre. Alguien bromeó con que quería la respuesta en una sola frase porque no tenía tiempo de leer el manual. Las respuestas se afilaron. Una persona contestó con el clásico tono de "entonces no toques un equipo", poco útil pero comprensible, y otra aclaró que era sarcasmo. Debajo de las pullas hay una división real. Algunos administradores quieren un sí o un no limpio. Otros saben que la respuesta es "sí, pero solo si tu configuración concreta pasa las comprobaciones y sigues los pasos".

Es frustrante, pero es honesto. La versión en una frase es sencilla: actualiza a la última 8.4, ejecuta pve8to9 --full, corrige todo lo importante y luego actualiza a la 9.2 nodo a nodo. Pero esa frase sola no va a proteger tu clúster. La guía completa existe porque los detalles feos importan: los repositorios, Ceph si lo tienes, la compatibilidad de los invitados, los tipos de máquina antiguos, los nombres de las interfaces de red, los paquetes retenidos, la salud del clúster y que las copias de seguridad estén listas. El hilo fue básicamente un recordatorio de que "¿puedo?" es una pregunta técnica y "¿debería?" es una pregunta de procedimiento.

Quien preguntaba ya pensaba en términos de procedimiento al planear vaciar un nodo cada vez, que es el instinto correcto. Lo que añadió la comunidad fue claro: además del plan de migración, hace falta un bucle de validación.

El plan nodo a nodo es sensato, pero el riesgo sigue ahí

Sacar todas las VM de un nodo, actualizarlo, probarlo y pasar al siguiente es justo el tipo de plan que suena lo bastante aburrido como para funcionar. Limita el radio de impacto y mantiene vivas las cargas de trabajo. Te da la oportunidad de detectar problemas raros propios de un host antes de que las seis máquinas estén en la nueva pila. Si el primer nodo actualizado se porta mal, te detienes, en lugar de seguir avanzando por el clúster porque una lista de tareas decía que hoy tocaba actualizar.

Pero las actualizaciones escalonadas generan su propia presión. Durante un tiempo, el clúster vive con versiones mezcladas. Eso no es un problema de por sí, pero sí es un motivo para ir con cuidado y no alargar el proceso en un limbo largo a medio actualizar. Quieres que cada nodo esté limpio antes de empezar, vaciado antes de tocarlo, actualizado con los ojos abiertos, reiniciado a propósito y probado antes de devolverle las cargas de trabajo. Luego repites el mismo ritual sin improvisar ni decidir que "este nodo seguramente es igual". A los clústeres les encanta castigar las suposiciones.

El plan original también planteaba una cuestión de orden con el backup: actualizar primero los seis nodos PVE y después el único PBS. Parece razonable, y añade una regla evidente: no empieces sin copias de seguridad verificadas. "Los trabajos suelen salir bien" y "el panel está en verde" no cuentan. Quieres que estén lo bastante verificadas como para saber qué restaurarías y dónde lo restaurarías si la actualización de un nodo se tuerce. Proxmox Backup Server forma parte de la red de seguridad, y la red de seguridad no debería tratarse como algo secundario, aunque su actualización vaya la última.

Un plan escalonado tiene la forma correcta. El peligro está en confundir una buena forma con una garantía. Sigue siendo una actualización mayor, y sigue mereciendo una ventana de mantenimiento, acceso a la consola, notas y un camino de vuelta.

Las historias de éxito con hardware viejo ayudaron, pero poco

Un usuario contó que actualizó servidores de la época de 2010 de la última 8.x a la última 9.x sin ningún tropiezo, y que esos sistemas incluso ejecutaban un kernel 7.0.x. Anima, porque el hardware viejo es donde la gente suele esperar el comportamiento más raro. Otro comentarista preguntó por un HP DL380 G7 con passthrough de hardware, intentando trasladar el éxito ajeno a su propio riesgo. La respuesta no encajaba del todo: el caso de éxito eran sistemas Dell R610 y R710 con CPU Xeon X5650, y el passthrough no estaba activado en ese host.

Ese intercambio es una pequeña lección de manual sobre el folclore de las actualizaciones. El éxito de otro es útil, pero hasta cierto punto. La misma época no significa el mismo hardware, y el mismo kernel no significa el mismo passthrough. La misma marca de servidor no garantiza el mismo firmware, controladora de almacenamiento, NIC, ajustes de BIOS ni comportamiento de IOMMU. Reconforta que las máquinas viejas sobrevivan a una versión nueva, pero eso no significa que tu equipo concreto vaya a hacerlo.

La mejor pregunta sobre hardware es "¿qué parte de mi configuración es rara?" y no "¿le funcionó a alguien?". El passthrough PCIe es raro. Las controladoras RAID antiquísimas pueden serlo, y también los drivers fuera del árbol del kernel, las redes personalizadas y los tipos de máquina de VM muy antiguos. Un comentarista advirtió que algunos modelos de máquina de VM antiguos ya no tienen soporte en Proxmox 9, y que cambiarlos puede incluso afectar a las licencias de software dentro de los invitados. Es el tipo de detalle que convierte una actualización tranquila del host en un dolor de cabeza en los invitados.

Así que sí, la historia de éxito con servidores viejos es una buena noticia. Te da permiso para ser optimista sin dejar de hacer una lista de comprobación, y ningún permiso para tomártelo a la ligera.

Las caídas autoinfligidas son lo que hay que temer

La frase más útil del hilo fue la de los problemas autoinfligidos, porque es ahí donde suelen morder las actualizaciones mayores. Proxmox no es especialmente peligroso y la 9.2 no está maldita. Los administradores se saltan un aviso, dan por bueno un repositorio, olvidan un paquete retenido, dejan sin tocar una configuración antigua, ignoran la salida del comprobador o actualizan por SSH sin plan de rescate y luego se sorprenden cuando la red desaparece.

El remedio es la disciplina, y no exige paranoia. Actualiza primero cada nodo 8.2.7 a la última 8.x y asegúrate de que el clúster está sano. Vacía el nodo y ejecuta el comprobador de actualización con la salida completa. Lee los avisos en lugar de tratarlos como texto decorativo, corrige lo que te diga y vuelve a ejecutarlo. Confirma las copias de seguridad y el acceso a la consola, y confirma que tienes controlados los tipos de máquina de VM antiguos, los dispositivos con passthrough, el almacenamiento y la configuración de red. Después actualiza, prueba y sigue adelante.

Puede sonar lento, pero es mucho más rápido que depurar un clúster roto mientras los invitados están caídos y todo el mundo pregunta si el servidor de backup está al día. Mantener los servicios en línea es solo la mitad del sentido de la actualización escalonada; también te da permiso para detenerte después del primer nodo si la realidad no está de acuerdo con el plan.

La comunidad dio tres respuestas a la vez. El lado confiado dijo que sí, que hay gente que lo ha hecho y funciona. El lado prudente dijo que primero a la última 8 y seguir la guía al pie de la letra. El lado impaciente dijo que leas el manual. Las tres apuntan en la misma dirección: pasar de Proxmox 8.2.7 a 9.2 no es un salto prohibido, y el camino seguro se parece más a una escalera que a un salto.

La mejor actualización es la que parece planificada hasta el fastidio

Esta pregunta resuena porque es de las que todo administrador acaba haciéndose, en público o para sus adentros. En algún momento la versión vieja es cómoda pero envejece, y la nueva es lo bastante estable pero sigue siendo nueva. El clúster es lo bastante importante como para no jugártela, pero no tan enorme como para tener un equipo dedicado a las actualizaciones, así que el equipo eres tú: mueves las VM, lees la guía, ejecutas las comprobaciones y esperas que el primer nodo vuelva sin sobresaltos.

Así se vive el momento de actualizar a Proxmox 9.2. El software puede estar listo, pero estar listo es algo local. Depende de tus nodos, tus invitados, tu hardware, tus copias de seguridad, tu tolerancia al tiempo de inactividad y tu paciencia con las instrucciones. En un entorno de seis nodos, la jugada ganadora es la repetición: el mismo proceso en cada nodo, ningún atajo porque el primero salió bien y ninguna vuelta de honor hasta que el último invitado esté funcionando donde debe y PBS siga haciendo su trabajo.

Así que sí, el camino de 8.2.7 a 9.2 puede tener sentido. La versión más inteligente es en realidad de 8.2.7 a la última 8.x y, desde ahí, comprobada, limpia y actualizada a la 9.2 nodo a nodo. Los usuarios que sonaban más seguros no prometían magia. Eran los que decían que sigas la guía, ejecutes el comprobador, corrijas los avisos y trates todo lo demás como riesgo autoinfligido.

No es una respuesta emocionante, pero es de las que mantienen todo funcionando.