Migrar más de 200 VMs a Proxmox es un problema de red

Sobre el papel, mover cientos de máquinas virtuales desde VMware a Proxmox parece una historia de cómputo centrada en el rendimiento del almacenamiento, la compatibilidad de CPU, los formatos de disco, las herramientas de importación, listas de verificación y barras de progreso.

En la práctica, nada de eso es lo que quita el sueño. El sudor frío viene de la red. Existe la versión limpia y diagramada que vive en un archivo de Visio de 2019, y luego está la red real, caótica y repleta de direcciones IP fijas en código, reglas de firewall olvidadas, licencias vinculadas a la dirección MAC, dependencias silenciosas de bases de datos y flujos de tráfico que nadie recuerda haber configurado.

Cuando mueves más de 200 VMs fuera de VMware ESXi, el cambio de hipervisor rara vez es lo que rompe el entorno. Todo lo que lo rodea sí suele serlo.

La importación funciona, pero las aplicaciones no

Casi cualquiera que haya hecho esto a gran escala cuenta una versión de lo mismo: el asistente de importación de Proxmox cumple su cometido. Los discos se transfieren, las máquinas arrancan, las CPUs responden y el consumo de memoria parece normal. Y de pronto, algo sutil falla.

Una aplicación inicia pero no puede comunicarse con su base de datos. Un informe programado se ejecuta pero nunca termina. Un servicio heredado no arroja ningún error, simplemente deja de realizar trabajo útil sin avisar a nadie. El monitoreo da la alarma horas después o, peor aún, un usuario lo nota varios días después de que la ventana de mantenimiento de la migración haya cerrado.

Esa es la zona peligrosa. Una avería silenciosa resulta más difícil de resolver que un fallo ruidoso, porque un fallo ruidoso al menos te da un punto de partida evidente. Y casi todos esos problemas silenciosos tienen su origen en la red.

La realidad de las configuraciones fijas siempre gana

En teoría, todo debería estar abstraído, con registros DNS en lugar de direcciones IP, descubrimiento de servicios en lugar de configuraciones estáticas y reglas de firewall documentadas y premeditadas.

En la realidad, muchísimos entornos crecieron de forma orgánica a lo largo de una década o más. Alguien configuró una IP fija porque era una solución «temporal». Alguien enlazó una aplicación directo a una base de datos porque resultaba más rápido. Alguien creó una regla de firewall de tipo hairpin para esquivar un problema raro y luego se olvidó de ella.

Esas decisiones no aparecen al exportar una VM. Solo salen a la superficie cuando el tráfico deja de fluir como solía hacerlo. Por eso tantos administradores experimentados, cuando se les pregunta cómo migrar a gran escala, hablan de monitoreo de tráfico, VLANs, tablas ARP y direcciones MAC en lugar de flags de CPU o formatos de disco.

Si no ves el tráfico, no conoces la aplicación

Uno de los consejos más habituales de quienes ya han pasado por migraciones grandes es tajante: la red no miente. Antes de mover nada, necesitas ver quién habla realmente con quién, lo cual suele diferir de quién crees que debería estar comunicándose.

Eso suele traducirse en alguna combinación de:

• Registros de firewall de tráfico permitido
• Exportaciones NetFlow o IPFIX hacia una herramienta de análisis de tráfico
• Espejado de puertos en conmutadores físicos o puentes virtuales
• Capturas de paquetes dirigidas a los sistemas más sospechosos

No es un trabajo vistoso, y a gran escala tampoco es opcional. Buscas patrones que nunca llegaron a la documentación: un servidor de aplicaciones conversando con un servidor de archivos en una subred antigua, una tarea por lotes que solo corre una vez a la semana, una base de datos heredada de la que todo el mundo depende aunque nadie quiera admitirlo. Aquí es donde la migración pasa de ser una tarea de virtualización a convertirse en arqueología.

El monitoreo también importa durante la migración

Muchos equipos ya dependen en gran medida de herramientas de monitoreo como Zabbix o sistemas equivalentes. Lo que cambia durante una migración es el nivel de confianza que depositas en ellos. A gran escala, el monitoreo se convierte en tu red de seguridad, y la pregunta pasa de «¿ha arrancado esta VM?» a «¿todas sus dependencias volvieron a estar en verde?».

Varios administradores describen el mismo flujo de trabajo: migrar una sola VM o un grupo reducido, esperar a que el monitoreo se estabilice y luego continuar. Si algo se rompe, añaden una nueva comprobación y repiten el ciclo.

Ese método no evita cada incidente, pero mantiene los problemas contenidos. Aprendes pronto qué aplicaciones son frágiles y a cuáles les da igual el hipervisor sobre el que se ejecuten.

Y sí, esto toma tiempo. Quienes han movido más de 300 VMs hablan de semanas, no de días. Cualquiera que prometa una transición limpia en un fin de semana tiene mucha suerte o se equivoca por completo.

IPs, VLANs y la ilusión de que todo sigue igual

Una de las formas más sencillas de mitigar riesgos es también una de las más aburridas: conservar las mismas direcciones IP. Cuando las VMs levantan con la misma IP, VLAN y puerta de enlace, desaparece una categoría entera de problemas. No hace falta modificar el DNS, las reglas de firewall no requieren reescritura y las aplicaciones no terminan de golpe intentando hablar con el destino equivocado.

Sin embargo, mantener todo idéntico solo funciona si tu red física y tu red virtual están realmente alineadas. Si tus switches top-of-rack no tienen las VLANs correspondientes configuradas en trunk, la VM puede arrancar a la perfección y aun así quedar aislada. Si el etiquetado cambia entre plataformas, el tráfico puede evaporarse sin dejar rastro. Si las tablas ARP no se actualizan con limpieza, aparecen problemas fantasma de conectividad que parecen aleatorios hasta que recuerdas su existencia.

Las migraciones dejan al descubierto los puntos débiles del diseño de red de esta forma. Proxmox no está haciendo nada extraño; el cambio simplemente empuja la realidad a la superficie.

Direcciones MAC: un detalle pequeño con grandes consecuencias

Las direcciones MAC son uno de esos detalles en los que no piensas hasta que un proveedor asocia sus licencias a ellas. Muchas cargas de trabajo en Linux toleran el cambio de MAC sin rechistar o admiten configurarse para mantener la anterior. Las VMs de Windows son menos indulgentes cuando el hardware virtual cambia bajo sus pies. A veces se adaptan sin queja y otras veces vuelven a enumerar dispositivos y provocan un desastre.

Luego están Oracle o cualquier otro software que considere una modificación de MAC o UUID como un evento de licenciamiento. Proxmox tiene poco que ver con eso. La virtualización abstrae el hardware, pero los proveedores de software comercial nunca recibieron esa circular.

Por qué «migrar despacio» es un consejo real

«Migrar una por una» suena evidente hasta que estás frente a una hoja de cálculo con 200 filas y la dirección del negocio preguntando cuánto va a tardar esto. Quienes han completado este proceso con éxito coinciden en que agrupar por lotes de forma inteligente supera con creces a precipitarse a ciegas.

Mueves un grupo pequeño, lo validas, corriges lo que se rompa y pones al día la documentación que debió existir desde un principio. Luego mueves el siguiente lote con menos sorpresas. No es un método rápido, pero es predecible, y la previsibilidad es lo que evita que las migraciones se transformen en emergencias con todo el equipo apagando fuegos.

Proxmox solo da la mala noticia

Lo que sorprende a quienes llegan de nuevas es que nada de esto es exclusivo de Proxmox. Escucharías los mismos relatos al migrar hacia KVM, Hyper-V o una nube pública. El cambio de hipervisor retira la manta de confort de la familiaridad, y de repente todas las suposiciones se ponen a prueba. Proxmox suele limitarse a dar la mala noticia; los problemas ya estaban ahí.

Lo que sí consigue es obligar a los equipos a encarar cómo se comunican realmente sus sistemas, lo cual resulta incómodo y útil al mismo tiempo.

La conclusión

Si estás planificando una migración grande de ESXi a Proxmox y dedicas casi todo tu tiempo a pensar en cómputo y almacenamiento, es muy probable que estés subestimando la parte más dura. El verdadero trabajo reside en la red: en los flujos indocumentados, en las dependencias que ya nadie mantiene y en las alertas de monitoreo que te avisan de que algo va mal pero no te dicen por qué.

Aborda esto como un proyecto de redes con un componente de virtualización, y no al revés. Si lo haces así, el asistente de importación resultará, de verdad, la parte más sencilla.