Migrar 1,500 máquinas virtuales de VMware vSAN a Proxmox: qué sale mal

Cuando "migración" deja de ser una palabra de moda y empieza a parecer un riesgo

Migrar un puñado de VM es una cosa, y enfrentarse a una cifra como 1,500 es otra. A semejante escala, el proyecto se convierte en una apuesta con consecuencias reales. Sobre el papel, el plan suena limpio: sacarlo todo de VMware vSAN y aterrizar sin sobresaltos en Proxmox. Pero casi de inmediato aparecen las grietas.

El primer problema llega rápido, porque no hay un puente limpio para salir de vSAN. Un ingeniero lo resumió sin rodeos: "La opción n.º 1 no va a funcionar… el trabajo de migración fallará". Eso obliga a aceptar una realidad incómoda. En lugar de migrar directamente, tienes que hacer pasos intermedios, saltos y malabares con capas de almacenamiento solo para sacar los datos, y cada paso extra añade tiempo, riesgo y la posibilidad de que algo se rompa a mitad de camino.

Al principio, la automatización parece la respuesta

Todo el mundo está de acuerdo en que esto no se puede hacer a mano, ni de lejos. Ahí entra el sueño del CI/CD, con runners de GitLab, playbooks de Ansible y aprovisionamiento con Terraform. Todo suena a un pipeline limpio: exportar, convertir, importar y listo.

Técnicamente, funciona. Una voz lo expuso con seguridad: "Terraform para aprovisionar la infraestructura y Ansible por encima para la migración". Ese es el ideal.

Luego se cuela la realidad. La automatización amplifica la complejidad, porque ahora cada error se multiplica por cientos de máquinas. Un playbook malo o una suposición equivocada sobre los drivers o la red, y en lugar de arreglar una VM estás apagando fuegos en decenas o cientos a la vez.

La conversación también incluye una confesión reveladora: hay gente que ya ha hecho automatización a gran escala, incluso con 8,000 servidores. Eso no lo hace fácil. Solo demuestra que se puede sobrevivir.

El problema de Windows del que nadie quiere hacerse cargo

Si Linux es la parte fácil de esta historia, Windows es donde la cosa se complica rápido, más en la práctica que en la teoría: drivers, problemas de arranque y pantallas azules acechando.

Algunos ingenieros han creado flujos de trabajo que a estas alturas parecen casi rituales. Instalar los drivers VirtIO antes de la migración. Quitar VMware Tools en el último momento posible. Arrancar una vez con SATA solo para "despertar" el driver y luego cambiar a VirtIO. No es elegante, pero funciona.

"Hago un arranque con el disco del sistema como SATA… y luego cambio", explicó una persona. Otra fue más allá y usó herramientas como devcon para inyectar los drivers antes incluso de que exista el hardware.

Aquí el tono pasa de la arquitectura a las tácticas de supervivencia. Cada uno tiene un método ligeramente distinto, y ninguno parece a prueba de balas, solo lo bastante probado como para fiarse.

Velocidad o tiempo de inactividad: elige uno

Una de las verdades más duras de todo este proceso es que no te llevas todo. Entre velocidad, poco tiempo de inactividad y sencillez, vas a sacrificar al menos una.

Algunos se apoyan en herramientas de backup como Veeam porque "la importación normal es demasiado lenta". Otros aceptan el golpe del tiempo de inactividad porque es más predecible. Aquí hay frustración, sobre todo por la falta de una replicación real hacia Proxmox.

"Hemos hecho copia de seguridad y restauración… pero el tiempo de inactividad es mayor del que queremos". Esa es la contrapartida dicha sin adornos: los métodos más rápidos suelen implicar más riesgo, y los más seguros te cuestan disponibilidad.

Cuando tratas con cientos o miles de sistemas, el tiempo de inactividad se vuelve un asunto político además de técnico, porque siempre hay alguien esperando a que esos sistemas vuelvan a estar en línea.

La capa oculta: el almacenamiento es el verdadero cuello de botella

Lo que sale de todo esto es que el almacenamiento, más que el cómputo o la automatización, es la verdadera limitación. vSAN no se lleva bien con las rutas de migración directa, lo que obliga a buscar alternativas: recursos NFS intermedios, sistemas de almacenamiento temporales, incluso levantar algo como TrueNAS solo para ir moviendo los datos.

A esta escala, mover los datos se convierte en el problema dominante, por delante de configurar las VM o de escribir scripts para los flujos de trabajo. Lo difícil es mover bits de un sitio a otro sin romperlos. Ahí es donde se frenan muchos planes, incluso los bien diseñados, porque los sistemas de base nunca se construyeron para cooperar.

Tres mentalidades, una decisión enorme

Si miras todas las perspectivas, surgen tres mentalidades distintas.

Primero están los optimistas. Creen en la automatización, los pipelines y la arquitectura limpia, y con las herramientas adecuadas esto no es más que un proyecto grande pero manejable.

Luego están los pragmáticos. Ya han hecho migraciones y saben que son desordenadas, están llenas de casos límite y se sostienen a base de scripts y apaños. Les importa más lo que funciona que lo que es elegante.

Y por último están los prudentes, preocupados por el tiempo de inactividad, la integridad de los datos y el enorme radio de impacto de los errores. Para ellos, cada paso es un cálculo de riesgos.

Ninguno se equivoca, porque una migración así es estratégica además de técnica. Mover las VM significa cambiar los cimientos sobre los que funciona todo, y una vez que empiezas no hay una forma limpia de pararte a mitad. Poca gente lo dice en voz alta, pero se nota en cada comentario.