De PVE 5 a 9: qué pasa cuando la infraestructura heredada se niega a jubilarse
Heredar la infraestructura de otra persona trae su propio tipo de estrés. No me refiero a la limpia y bien documentada, ni a la de "esto lo migramos el próximo trimestre". Me refiero al stack con años de uso encima, crítico para el negocio y algo polvoriento que lleva años funcionando porque una persona sabía exactamente cómo iba, y ahora esa persona ya no está.
Esa es la situación de una pequeña empresa que todavía funciona con Proxmox VE 5.4-15, una versión tan antigua que parece una cápsula del tiempo. Y ahora tiene que saltar hasta la 9, varias versiones mayores de golpe.
Cuando "todavía funciona" no basta
Sobre el papel, el montaje no era enorme: dos nodos, un puñado de VMs y un NAS para las copias de seguridad, sin nada exótico en la mezcla.
Uno de los nodos ya iba renqueando con la 8.x antes de que sus discos empezaran a fallar. Se sustituyó por un nuevo micro servidor Supermicro con una instalación limpia de Proxmox 9, y la cosa fue, la verdad... fluida. Las copias de seguridad con Proxmox Backup Server funcionaban y la migración desde el nodo moribundo salió bien. Hasta aquí, todo bien.
Luego está la vieja máquina con PVE 5, que es donde viven los fantasmas de verdad.
El NAS que se ahoga
En teoría, hacer copia de seguridad de las VMs críticas que quedan debería ser sencillo. En la práctica, enviar las copias desde PVE 5 al NAS casi lo deja fuera de combate.
El NAS es una caja TerraMaster en RAID 5 con una sola NIC de 1Gb. No ejecuta las VMs; solo hace de destino de copias de seguridad montado. Pero cuando arranca un trabajo de backup, todo se ralentiza hasta arrastrarse. El NAS se atasca, la red gime y tienes la sensación de estar acercándolo un trabajo más a la jubilación.
El NAS ya está en la lista de renovaciones, pero el sustituto todavía no ha llegado. Entonces, ¿qué haces cuando el propio acto de proteger tus datos puede ser lo que rompa tu almacenamiento?
La respuesta de la comunidad fue de un pragmatismo refrescante: bajar el ritmo. Limitar la velocidad no es vistoso ni parece una "gran solución", pero configurar bwlimit en /etc/vzdump.conf para poner un tope a la transferencia, por ejemplo 50MB/s, puede bastar para que el NAS no se ahogue bajo la presión de escritura. La misma idea funciona en el lado de PBS con reglas de control de tráfico. No es glamuroso ni moderno, pero funciona.
La tentación de saltarse pasos
Siempre está esa idea al fondo de la cabeza: ¿y si actualizamos sin más, en el sitio? Pasar de la 5 a la 6, de la 6 a la 7, de la 7 a la 8 y de la 8 a la 9, siguiendo rutas lentas, metódicas y con soporte.
El problema es que esto es un negocio en funcionamiento, y las VMs en cuestión ejecutan un software a medida antiquísimo que nadie sabe muy bien cómo reconstruir desde cero. Una de ellas es un Windows 7, sin acceso a internet, que ejecuta un servicio central y que resulta intocable de la forma más aterradora. Las otras son Windows 10, con poca conexión pero igual de críticas.
Si se rompen, no hay un script de reinstalación esperando en un repositorio de Git, ni hay documentación. Solo hay ansiedad. Por eso este salto de la 5 a la 9 se parece menos a una actualización y más a una operación a corazón abierto.
El aviso de i440FX que no desaparece
Tras migrar algunas VMs al nodo con Proxmox 9, aparece un aviso nuevo:
Machine type 'pc-i440fx-5.1' is deprecated. Current machine version is subject to deletion.
No es un error, y todo arranca, pero es una cuenta atrás.
El antiguo tipo de máquina i440FX emula un chipset heredado basado en PCI. El Proxmox moderno prefiere Q35, que emula una plataforma basada en PCIe. Sobre el papel suena a algo menor, solo hardware virtual por debajo. En realidad, es un cambio de plataforma.
Pasar de i440FX a Q35 es algo más que cambiar un desplegable. Puede provocar que se reinicialicen los dispositivos, que aparezcan NICs virtuales nuevas y una topología PCI nueva, así que Windows puede ver un hardware completamente nuevo. Eso puede significar:
- Posibles direcciones IP nuevas
- Baile de drivers
- Tropiezos con la activación
- Esa horrible pausa de "Instalando software de controlador de dispositivo..."
En una VM de laboratorio, no pasa nada. En una máquina con Windows 7 que ejecuta software central del negocio que nadie quiere tocar, es un reinicio con los nudillos blancos.
El consejo de los administradores veteranos fue directo: trátalo como hardware nuevo, planifica la nueva detección de dispositivos, cuenta con tener que reconfigurar la red y no des por hecho que será invisible. También dijeron que no cundiera el pánico. En la mayoría de los casos funciona; solo hay que hacerlo con cuidado y de forma planificada.
Una regla no escrita: no mezcles generaciones en un clúster
Un consejo destacó con claridad: no metas en un clúster la 5.x con la 8.x o la 9.x. Solo las diferencias de API ya pueden dar dolores de cabeza, y no merece la pena. Si sigues en la 5, no intentes montar un clúster híbrido tipo Frankenstein.
Mejor borrón y cuenta nueva. Instala desde cero, restaura las copias de seguridad, actualiza el hardware virtual una vez que estés en una versión moderna y después actualiza las herramientas del invitado. Esa ruptura limpia suele ser menos arriesgada que ir parcheando poco a poco a través de media década de cambios.
El argumento de "copia el disco y ya"
Siempre hay alguien que lo sugiere, y tiene su parte de razón. Si el disco de la VM es un archivo qcow2, haz rsync. Si es LVM, usa dd y ncat. Apaga la VM, copia el disco y vuelve a crear la configuración a partir de /etc/pve/.
Es técnicamente correcto y emocionalmente aterrador, porque copiar una imagen de disco da la sensación de saltarse el camino "oficial". Parece un apaño con cinta americana, aunque no lo sea.
Las VMs de Proxmox son sobre todo archivos de disco y texto de configuración, sin ninguna base de datos mágica escondida en algún sitio. Si entiendes lo que estás copiando, es perfectamente válido. Lo que importa es el tiempo de inactividad: la VM tiene que estar apagada, sin medias tintas. Y en muchas migraciones, esa copia directa del disco es más rápida y castiga menos a un almacenamiento frágil que los ciclos repetidos de copia de seguridad.
También está la vía de Veeam
Para las VMs de Windows surgió otra opción: tratarlas como máquinas físicas. Herramientas como Veeam Backup & Replication pueden hacer copia de seguridad de una VM Windows a nivel de sistema operativo y restaurarla en un entorno nuevo, lo que abstrae el salto de hipervisor. Es atractivo cuando la distancia entre versiones del hipervisor parece peligrosa.
Eso sí, añade otra capa, otra herramienta y otra dependencia, y a veces lo más sencillo de verdad es lo más seguro.
El peso emocional de los sistemas heredados
Hay un detalle en esta historia que importa más que cualquier límite de ancho de banda o que la opción del tipo de máquina: este entorno era de alguien a quien le importaba mucho mantenerlo en marcha, y ahora es otra persona la que carga con esa responsabilidad.
Eso cambia cómo te enfrentas al riesgo. No quieres ser quien "modernizó" todo hasta provocar una caída, ni quien rompió la única VM con Windows 7 que ejecuta una aplicación a medida antiquísima que nadie entiende. Así que avanzas con cuidado. Pruebas las copias de seguridad una y otra vez, verificas los trabajos de PBS y preguntas a la comunidad antes de tocar los tipos de máquina. Respetas el sistema, aunque esté anticuado.
Qué pasa de verdad cuando lo heredado se niega a jubilarse
La infraestructura heredada no falla de golpe; se degrada por capas. Primero son los discos, luego los avisos, luego las versiones sin soporte, luego los cuellos de botella de las copias de seguridad. Cada capa susurra lo mismo: "Tendrías que haber actualizado antes".
Pero las pequeñas empresas no siempre tienen presupuesto para actualizar, hardware de repuesto o ventanas de inactividad. Así que entornos como este sobreviven más de lo que deberían, y cuando por fin llega la actualización, es un salto de años.
La buena noticia es que Proxmox es sorprendentemente resistente entre generaciones. Con copias de seguridad como es debido, copias de disco en frío y transiciones de hardware cuidadosas, saltar de la 5 a la 9 es factible. La mayor parte del riesgo está en la carga de trabajo a medida desconocida que hay dentro de esas VMs Windows, más que en el propio Proxmox.
El manual que sale de todo esto
Reducida a lo esencial, la estrategia queda así:
- Asegura copias de seguridad verificadas con Proxmox Backup Server.
- Limita la velocidad de las copias para no aplastar un hardware de NAS viejo.
- Evita los clústeres con versiones mayores mezcladas.
- Restaura en nodos nuevos con 8.x/9.x.
- Actualiza el hardware virtual de forma deliberada.
- Prueba antes de tocar los tipos de máquina.
- Trata el paso de i440FX a Q35 como una migración de plataforma, no como un cambio cosmético.
Es una ejecución sencilla y disciplinada, y esa disciplina es lo que mantiene vivas a las pequeñas empresas durante transiciones como esta.
¿Y esa máquina con Windows 7?
Sigue ahí, sigue funcionando y sigue aislada de internet como una pieza de museo tras una vitrina. Tarde o temprano tendrá que moverse, jubilarse o virtualizarse dentro de otra VM como una especie de muñeca rusa digital. Por ahora, solo necesita sobrevivir al salto de hipervisor, y sinceramente, con eso basta.
A veces modernizar significa llevar contigo lo que ya funciona, con cuidado y con respeto, sin romper lo que mantiene las luces encendidas.