Cómo migramos 198 máquinas virtuales de VMware ESXi a Proxmox VE
sin detener la operación
Siete hosts ESXi en dos ciudades, 198 máquinas virtuales y 47.6 TB de disco de una institución financiera en México. Del 21 de septiembre al 14 de octubre de 2026: 162 servidores ya fuera de VMware, cinco equipos reinstalados como Proxmox VE y ningún cambio de IP, nombre o switch.
Siete ESXi, dos ciudades, una renovación que llegó con otro precio
Cuatro hosts en la Ciudad de México y tres en una segunda sede, con cargas de producción, UAT y desarrollo: Windows Server (2012 a 2025) y Linux (Ubuntu, Rocky), SQL Server, Oracle, Kafka, Redis, Kubernetes, GitLab y controladores de dominio. Todo con IP fija en VLAN de producción, desarrollo y UAT, y respaldos con Veeam.
La condición del cliente fue clara: nada cambia para los usuarios. Misma IP, mismo nombre, misma MAC, el mismo switch sin tocar, y cada servidor vuelve a su mismo hardware.
Un nodo de paso, un carril de copia y el regreso en caliente
- Nodo de paso con Proxmox VE, unido a cada ESXi por un enlace temporal de 10 Gb/s y a las mismas VLAN por el troncal. Recibe las VMs de un host mientras ese host se reinstala.
- Copia por NFS con vmkfstools: sólo los bloques en uso, desde el propio ESXi hacia la zona de paso; importación con
qm importdisky discos en ZFS con compresión. - Reinstalación del host como Proxmox VE 9 sobre el mismo equipo, un almacenamiento por cada datastore que tenía, la misma disposición de tarjetas de red. Los discos de VMware se conservan sin formatear hasta el visto bueno.
- Clúster con una sola consola, dirección flotante y voto adicional en el nodo de paso; regreso en caliente con
remote-migrate: la VM se copia en marcha y se pausa milisegundos. - Portal del cliente con el avance en vivo por máquina virtual, lista de verificación, vistos buenos y acta de entrega.
Una ficha, un carril desatendido y una validación contra la foto previa
Cada máquina virtual tiene una ficha con su IP, su MAC, su tipo de sistema, su memoria para la estancia y su destino. El carril la lee y ejecuta los pasos sin intervención; lo que no cuadra detiene esa VM, no la ventana.
Imagen previa
Con el servidor en servicio: puertos TCP que atiende y servicios que corren (en Windows, los que están en Automático). Es la referencia.
Apagado ordenado
Desde VMware Tools o desde dentro por SSH. Nunca se fuerza sin acuerdo; si un servidor no obedece se espera, y se avisa.
Copia e importación
vmkfstools al NFS del nodo de paso por el enlace de 10 Gb/s; importación a ZFS; disco de arranque por SATA en Windows; tarjeta VirtIO con la misma MAC.
Arranque sin red y conexión
La VM arranca con el cable desconectado, se verifica que vive, y se conecta a su VLAN. Desde ese segundo cuenta la vuelta a la red.
Validación
IP fija aplicada, puerta de enlace, DNS, canal seguro con el dominio, escritorio remoto, agente de Proxmox y los servicios comparados contra la imagen. Lo que no levantó solo se levanta y se reporta.
Cierre
VMware Tools fuera con un reinicio dentro del nodo, disco movido en vivo de la zona de paso a su almacenamiento definitivo, arranque automático activado.
Las seis rondas, en cifras
Corte = del apagado ordenado en VMware a que el servidor vuelve a responder en la red con su IP. Las ventanas de salida arrancan a las 22:00; de día no se toca producción.
| Ronda | Fechas | Equipo | VMs | Salida de VMware: corte por servidor | Regreso a su equipo, ya como Proxmox |
|---|---|---|---|---|---|
| 1 | 21 al 25 de septiembre | Dell R440 | 14 | mediana 38 min (14 min a 1 h 22 min) | en caliente · promedio 31 ms (11 a 80) |
| 2 | 28 al 30 de septiembre | Dell R550 | 23 | mediana 18 min (7 a 59 min) | en frío · promedio 3 min 13 s (35 s a 5 min 36 s) |
| 3 | 1 al 5 de octubre | Dell R760xs | 31 | dos noches: 19 servidores con promedio de 9 min, 12 con 26 min | en caliente · promedio 63 ms (27 a 102) |
| 4 | 3 al 5 de octubre | Dell | 46 | un domingo, cuatro olas, las bases de datos al final | en caliente · promedio 90 ms (14 a 345) |
| 5 | 9 y 10 de octubre · segunda ciudad | Dell R550 | 23 | mediana 14 min (4 a 40 min) | en caliente · promedio 69 ms (25 a 329) |
| 6 | desde el 13 de octubre · segunda ciudad | Dell R760xs | 25 de 40 | primera noche: mediana 3 min 48 s (1 min 21 s a 21 min 34 s) | programado para el fin de semana |
De la primera ronda a la sexta el corte mediano al salir de VMware bajó de 38 a 4 minutos: el método se afinó con cada host. La copia real por el enlace de 10 Gb/s fue de 140 a 300 MiB/s según el servidor; en la ronda 3, 838 MiB/s en el regreso. En la noche del 13 de octubre, 25 servidores salieron de VMware entre las 22:01 y la 01:24.
Lo que falló y cómo quedó en el método
Cada incidencia de las seis rondas tiene hoy un paso en el carril o una regla en la ficha. Estas son las que más tiempo costaron.
Windows no arranca con el disco en VirtIO
El controlador VirtIO instalado en VMware queda en el almacén de drivers pero no amarrado al dispositivo de arranque. Regla desde la primera ronda: el disco de sistema entra por SATA, Windows arranca, y después se cambia a VirtIO SCSI con la VM ya en Proxmox.
La IP fija se queda en la tarjeta vieja
Al cambiar la tarjeta de red virtual, Windows la trata como nueva y vuelve a DHCP. El guion la detecta y vuelve a aplicar la IP, la máscara, la puerta y los DNS en el momento, con la misma MAC de siempre.
El desinstalador de VMware Tools se cuelga 25 minutos
Fuera de VMware el servicio no responde y la desinstalación espera. Primero se termina el proceso, luego se desinstala, y se comprueba dentro de la VM: el «fin» del guion no es éxito. Se hace en paralelo, fuera del carril de copia.
Tipo de procesador: «host» no siempre sirve
Con el procesador expuesto tal cual, algunas Windows arrancaban con fallas por instrucciones que el hipervisor no ofrece igual. Se fijó un modelo de CPU estable para la estancia y otro específico para Windows Server 2025, que exige un conjunto de instrucciones distinto.
Nombres con acento o guion bajo
Proxmox exige nombres válidos de DNS. Dos servidores con «í» y «_» en el nombre rechazaron la creación a mitad de la noche; el carril ahora translitera solo y lo reporta.
La unidad de CD que pausa la máquina
Al cambiar el ISO de drivers en caliente, un sistema que tenía bloqueada la bandeja hizo que el ESXi abriera una pregunta y pausara la VM. Se contesta de inmediato y se revisa la pregunta después de cada cambio de CD; nunca se deja abierta.
Contenedores que no vuelven solos
Servicios de Docker con política de reinicio «no» no regresan tras el primer arranque en Proxmox. La revisión previa los lista y el cliente decide si cambian a «siempre» antes de la ventana.
Discos repartidos en dos controladores
Un servidor con el sistema en SCSI y los datos en SATA quedó con el disco de datos suelto tras el ajuste. Se reconectó en caliente como VirtIO SCSI y Windows lo volvió a poner en línea con su letra de siempre; el carril ya respeta la ranura de arranque.
Lo que no se pudo: Windows Server 2012
Los drivers VirtIO actuales no traen firma válida para 2012 y el instalador no corre. El servidor se migró con su tarjeta Intel emulada, tomó IP por DHCP y, sin agente, no se pudo fijar desde fuera: regresó a VMware en 25 minutos, intacto, y espera drivers firmados.
Cinco reglas que hoy aplicamos a cualquier migración
- Se mide, no se estima. Los GiB definidos no son los usados: la primera planeación con tamaño definido sobreestimó la copia 3 veces. Hoy se planea con los bloques en uso y la velocidad medida en el enlace real.
- El orden es por criticidad y las bases al final. Primero lo apagado (cero corte), luego desarrollo y UAT, después producción de menor a mayor, y las bases de datos cierran la noche con su respaldo reciente confirmado.
- La memoria del equipo de paso se reparte, no se promete. Cada VM entra con memoria recortada según su uso real y recupera la original al volver a su equipo, con un reinicio ordenado por servidor.
- Lo que el cliente ve es lo que pasa. El portal muestra por máquina virtual la hora de apagado, el tiempo fuera, la copia, la vuelta a la red y qué se comprobó; y ahí mismo da su visto bueno.
- El regreso siempre está listo. La VM original queda apagada e intacta en VMware y los discos del ESXi no se formatean hasta la aprobación. Cuando un servidor no se pudo validar, se encendió el original en minutos y la operación no se enteró.
¿Tu renovación de VMware también llegó con otro precio?
Con un diagnóstico sin costo te decimos cuántas rondas, qué ventanas y qué cuidados necesita tu plataforma. Sin comprar hardware nuevo.