Migrar de VMware a Proxmox: el disco llega entero, Windows no arranca, y el fallo es de dos semanas antes

El asistente de importación de Proxmox VE hace su trabajo: se trae la máquina virtual desde ESXi sin que tengas que tocar un .vmdk a mano. Luego arrancas ese Windows y aparece una pantalla azul. El asistente no ha hecho nada mal. El error se cometió el día que alguien escribió «migrar las VMs de Windows» como una línea del plan de la noche del sábado.

Hay una diferencia entre copiar una máquina y mudarla. Copiar es un problema de ancho de banda: se resuelve con más red, más disco y más paciencia, y es aburridamente predecible. Mudar arrastra además una decisión que el sistema invitado tomó cuando se instaló, hace años, sobre qué controladora de disco iba a encontrarse la próxima vez que arrancara. Esa decisión no viaja dentro del disco virtual y no se puede cambiar desde el hipervisor. Se cambia dentro de Windows, con Windows encendido. Y cuando la migración va mal, Windows ya no arranca.

El asistente hace bien su parte, y conviene decirlo

Proxmox VE 8.2, publicada el 24 de abril de 2024, incorporó el importador de ESXi como un plugin de almacenamiento, integrado en la API y en la interfaz web. Se apunta el ESXi como si fuera un almacén más, aparecen las VMs, se eligen y se importan con buena parte de su configuración traducida al modelo de Proxmox. No es un script de terceros ni un qm importovf con notas de foro: es funcionalidad de producto. Desde entonces ha llovido —vamos por la rama 9— y el importador ha seguido mejorando; lo que no ha cambiado es lo que viene a continuación.

Sus límites están documentados, y están todos. El wiki de Proxmox avisa de que la importación «puede ser significativamente más lenta si la VM tiene instantáneas», de que «importar una VM con discos sobre un almacenamiento vSAN de VMware no funciona», de que «los discos de VM cifrados, por ejemplo mediante una Storage Policy, no se pueden importar», de que un almacén con caracteres especiales como el + en el nombre «podría no funcionar», y de que aunque se puede importar a través de vCenter, hacerlo «reducirá drásticamente el rendimiento». Recomienda apagar la VM en origen para tener un estado consistente, y declara que la importación se ha probado desde ESXi 6.5 hasta 8.0.

Fíjate en qué tienen en común esas cinco advertencias: todas hablan del transporte. De cómo de rápido llega el disco y de si llega. El wiki sí tiene, además, una sección entera de preparación del sistema invitado, y es buena; volveremos a ella. Pero es una lista de qué: no dice cuándo hay que hacer cada cosa, ni qué cuesta cada una si te la dejas para la noche del sábado. Ese hueco la documentación no tiene por qué llenarlo, y es de lo que va el resto de este artículo.

La frase del wiki que explica el bucle

La documentación oficial de Proxmox sobre los drivers paravirtualizados de Windows lo dice en una sola frase, y es la frase más importante de toda esta historia: «To switch an existing Windows installation to use the VirtIO-SCSI drivers and boot from them, it needs to see a disk requiring the driver before». Para que una instalación de Windows ya existente use los drivers VirtIO SCSI y arranque desde ellos, necesita haber visto antes un disco que requiriese ese driver.

Es una dependencia circular. Ese disco no existe mientras la VM vive en ESXi, donde la controladora suele ser una LSI Logic —Parallel o SAS— o una VMware Paravirtual, y en instalaciones más recientes puede ser NVMe. Existe en Proxmox, pero para entonces Windows ya no arranca y no puede verlo. El antes de la frase cae en un momento en el que la máquina todavía está en el hipervisor que estás abandonando, y ese es todo el problema: no es folklore de foro ni una peculiaridad de una versión, está escrito en el wiki del fabricante.

El propio wiki de migración da la salida de emergencia, y es la que casi todo el mundo acaba usando: cuando el invitado es Windows, «el tipo de bus del disco hay que cambiarlo del SCSI por defecto a IDE o SATA», porque esos drivers «normalmente deberían estar siempre instalados». Traducido: arrancas por una controladora emulada, más lenta, para poder entrar en el sistema. Funciona, lo dice el wiki y lo hemos hecho. Lo que también es cierto es que a esas alturas la migración ya se ha convertido en una reparación, y una reparación se hace con la ventana corriendo.

El procedimiento oficial es correcto. No es un plan

La receta documentada para salir del bucle es el truco del disco señuelo, y funciona: con la VM ya arrancando por SATA, metes la ISO de drivers VirtIO en el lector y añades un disco temporal de 1 GB con bus SCSI y, en Opciones, la controladora SCSI de la VM puesta a VirtIO —son dos ajustes, no uno, y el segundo es el que se salta todo el mundo—, o bien VirtIO Block. El wiki matiza lo que muchos tutoriales dan por hecho: «el disco debería conectarse en caliente; si no, hay que reiniciar la VM». Windows lo detecta como dispositivo desconocido, le instalas el driver desde la carpeta vioscsi de la ISO, apagas, desenganchas el disco señuelo y el de arranque, y vuelves a enchufar el de arranque ya como VirtIO SCSI. Después viene el aviso que más veces se olvida —«adapta el orden de arranque en la pestaña de opciones de la VM; asegúrate de que el dispositivo de arranque principal sigue siendo el disco de arranque antiguo»— y, por si acaso, el plan B: «si la VM no arranca, puedes desenganchar y volver a enganchar el disco como IDE o SATA para repetir el procedimiento con el disco señuelo».

Lo que viene ahora es lectura nuestra, no del wiki: ese procedimiento resuelve una máquina, no resuelve una migración. Cuenta lo que cuesta por VM y verás la forma del problema. Un apagado y un arranque limpios adicionales de un Windows Server —dos y dos si el disco no se conecta en caliente y toca reiniciar, que es el caso que el propio wiki contempla—. Un paso manual dentro del invitado, con ratón: automatizarlo por la API de Proxmox exige que el invitado ya tenga el agente de QEMU dentro y vivo, que es justo lo que una VM recién importada de ESXi no tiene. Un cambio de orden de arranque que no se puede olvidar. Y todo ello, obligatoriamente, después de que el disco esté copiado.

La aritmética que rompe la ventana

No te vamos a dar minutos por máquina, porque no los tenemos medidos de una forma que podamos defender: dependen del tamaño del disco, del almacenamiento de destino y de si a ese Windows le da por instalar actualizaciones justo al apagarse, que es exactamente cuando le da. Lo que sí es fijo, y es lo único que hace falta para ver el problema, es la forma del coste: es por máquina, es secuencial y cae dentro de la ventana.

Con tres máquinas de Windows cabe. Con cuarenta no cabe, y lo malo es cómo no cabe: el plan no revienta a la mitad y se para. A las seis de la mañana alguien mira el reloj y decide dejar las diez últimas arrancando por SATA de momento. Ese «de momento» es el que aparece meses después en un ticket de rendimiento que nadie relaciona con la migración, porque para entonces la migración ya se dio por cerrada y por exitosa. Se cerró: solo que una parte del trabajo se quedó abierta con otro nombre.

La única parte de este trabajo que tiene una restricción de orden dura —tiene que pasar antes, no puede pasar después— es justo la que el plan estándar coloca después. Todo lo demás se puede empujar con más red, más manos o más noche, y por eso todo lo demás se planifica bien: porque admite que le echen recursos encima cuando va mal.

La solución no es correr más: es mover el trabajo de fecha

El driver VirtIO se puede meter en el almacén de controladores de Windows mientras la VM sigue viva y dando servicio en ESXi, y dejarlo marcado para que se cargue en el arranque. Cuando el disco cambie de controladora, Windows no necesitará «haber visto antes» nada: el driver ya está dentro y ya está marcado. El bucle se deshace por el único sitio donde deshacerlo no cuesta ventana, que es el pasado. En el destino también se puede —el wiki lo explica y funciona, y hay más rutas que se hacen enteras en Proxmox— pero todas se pagan en apagados, arranques y ratón, con la noche corriendo.

Hay guías públicas con scripts que hacen justo eso, y describen el resultado sin rodeos: «inyectando el driver en el almacén de controladores de Windows y marcándolo para que cargue durante la inicialización, eliminas por completo el bucle de conmutar hardware». Nosotros no hemos auditado ese código y no vamos a decirte que lo ejecutes a ciegas en tu controlador de dominio; si lo usas, léelo primero y pruébalo en una máquina que no importe. Lo que nos interesa aquí no es la herramienta concreta, que puede ser un script, una preparación manual o lo que tu proveedor te ponga delante. Lo que nos interesa es que el trabajo cambia de casilla en el calendario: sale de la madrugada del sábado, con la VM apagada y con vuelta atrás incómoda, y se va a un martes por la tarde, con la VM encendida, con el servicio funcionando y con la posibilidad de deshacer sin que se entere nadie.

El driver no es lo único que se queda dentro del invitado

Hay al menos otra tarea con exactamente la misma forma, y también está en el wiki: «en Windows, plantéate quitar la configuración de red estática, si la hay. Después de la migración, el adaptador de red cambiará y Windows mostrará un aviso si configuras la misma dirección IP en otro adaptador, aunque el anterior ya no esté presente». Es el mismo patrón: se toca antes, el síntoma sale después, y el síntoma es confuso —Windows quejándose de una IP duplicada con una tarjeta de red que ya no existe—. A las cuatro de la mañana eso son veinte minutos de buscar por el sitio equivocado.

Y hay una tercera con la misma forma que es peor que una pantalla azul, porque el castigo no es no arrancar sino no descifrar. El wiki lo dice sin dramatismo: «si se usa cifrado de disco completo en la VM y las claves están guardadas en un dispositivo TPM virtual, plantéate deshabilitarlo. Actualmente no es posible migrar el estado del vTPM a Proxmox VE desde VMware. Asegúrate de tener disponibles las claves manuales para descifrar la VM, por si acaso». Traducido a lo que pasa: BitLocker con la clave en el vTPM, el vTPM no viaja, y la clave de recuperación estaba en un sitio que alguien tiene que haber ido a buscar antes. Otra vez el mismo antes.

Ninguna de estas tareas es un secreto nuestro: el wiki abre su sección de preparación pidiendo «quitar cualquier herramienta de invitado específica del hipervisor antiguo, porque después puede ser difícil quitarlas» —eso son las VMware Tools— y sigue con la red, las reservas de DHCP y el vTPM. Todas están escritas y todas son correctas. Lo que le añadimos nosotros es una sola cosa, y esta sí como práctica propia: instalar el agente de invitado de QEMU antes de mover, no después, porque es lo que te permite tratar al invitado desde fuera cuando ya está en el destino. Y ojo, que la red de la máquina es solo la mitad: la otra mitad es la del anfitrión, que en Proxmox no vive en un sitio central sino en cada nodo, como contamos en migrar a Proxmox: la red la guarda cada nodo.

Esto no va de VirtIO. Va de cómo se escriben los planes

Toda migración tiene una lista corta de tareas que solo se pueden ejecutar en el sistema que estás a punto de retirar. Son las únicas con un orden que no se puede negociar, y son justamente las que se pierden. Se pierden porque los planes se escriben desde el evento hacia atrás: «el sábado hacemos A, luego B, luego C». Lo que hay que hacer el martes anterior no tiene casilla en esa tabla, así que no existe, y como no existe nadie lo asigna.

El fallo de arranque de esa VM es previsible. Está documentado, tiene nombre y lleva años ahí. Lo que no es inevitable es la avería: tres horas de ventana consumidas, un servicio que no vuelve el lunes y una migración que el comité recordará como «aquello que salió mal». Esa parte fue una decisión de calendario, tomada dos semanas antes por alguien que estaba dibujando una tabla y no se dio cuenta de que le faltaba una columna a la izquierda.

Por eso el artículo hermano de este es el del plan de vuelta atrás, y conviene no confundirlos. Preparar el invitado antes reduce la probabilidad de tener que usar la vuelta atrás; no reduce ni un poco la necesidad de tenerla escrita. Son dos controles distintos sobre el mismo riesgo, y quien sustituye uno por el otro se queda sin los dos.

Tres fechas en vez de una

Dos semanas antes. Preparación del invitado, en ESXi, en horario de oficina y con las máquinas encendidas: driver VirtIO dentro y marcado para arranque, configuración de red estática anotada y retirada donde toque, VMware Tools fuera. Y el inventario, que es la parte que nadie hace: no es lo mismo un Windows Server 2012 R2 que un 2022, ni una controladora LSI Logic que una VMware Paravirtual o una NVMe. Si no sabes cuántas de cada tienes, no tienes un plan, tienes una intención.

Una semana antes. Una máquina real migrada de verdad —la menos importante que tengas— y dejada corriendo en el cluster nuevo siete días. No para comprobar si el asistente funciona: funciona. Para descubrir cuáles de estos pasos hacen falta en tus máquinas y cuáles no, y para que el equipo haga el procedimiento una vez con luz, sin prisa y con la posibilidad de equivocarse. Un ensayo que no puede salir mal no es un ensayo.

La noche. Copiar. Nada más. Si la noche de la migración alguien está instalando drivers dentro de un Windows, la preparación no se hizo: se aplazó, y se aplazó hasta el único momento en el que ya no se puede hacer bien.

Cuándo esto no va contigo

Si todas tus máquinas son Linux razonablemente moderno, esto es mucho ruido para poco: los módulos virtio suelen venir en el initramfs y la VM arranca sin que hagas nada. «Suelen» es literal, y en la familia RHEL —Rocky, Alma— no hace falta que nadie lo estropee: dracut genera el initramfs en modo host-only por defecto, con los módulos del hardware que veía el día que se generó, que era el de VMware. El síntoma entonces no es una pantalla azul sino un kernel panic, y es la causa clásica de que una VM de Linux no arranque tras pasar de VMware a KVM. Se comprueba con la máquina encendida, dos semanas antes, con una orden: lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio en Debian y Ubuntu, lsinitrd | grep virtio en RHEL y derivadas. Si no sale nada, ya sabes qué toca hacer y cuándo.

Y si tienes tres máquinas de Windows y una tarde entera por delante, la vía oficial del wiki te sirve perfectamente y no necesitas nada de lo que hemos contado: haz el disco señuelo, instala el driver y sigue. Este artículo va de escala, del punto en el que multiplicar un procedimiento manual por el número de máquinas deja de caber en una noche. Y antes de todo esto sigue estando la otra pregunta, la que también hay que hacerse en voz alta: cuándo no migrar de VMware a Proxmox. A veces la respuesta correcta es quedarse.

Trabajamos con Proxmox desde las ramas 3.x y con vSphere desde versiones bastante viejas, y hemos hecho las dos cosas: migrar empresas de VMware a Proxmox y recomendar a otras que se quedaran donde estaban. No recordamos ninguna migración que fuera mal por el hipervisor de destino. Las que se complican, se complican por el calendario.

Nota de fuentes

Del wiki oficial de Proxmox Migrate to Proxmox VE salen las limitaciones del importador de ESXi que citamos entre comillas (lentitud con instantáneas, vSAN no soportado, discos cifrados por Storage Policy, nombres de almacén con caracteres especiales como el +, la caída de rendimiento al importar vía vCenter), la recomendación de apagar la VM en origen para tener un estado consistente, el rango de versiones probado (ESXi 6.5 a 8.0), la indicación de cambiar el bus del disco de SCSI a IDE o SATA cuando el invitado es Windows —porque esos drivers «normalmente deberían estar siempre instalados»— y su sección de preparación entera, de la que citamos tres puntos: quitar las herramientas de invitado del hipervisor antiguo (las VMware Tools), la configuración de red estática y el adaptador que cambia tras la migración, y el cifrado de disco completo con las claves en un vTPM cuyo estado no se puede migrar desde VMware. Esa sección incluye además apuntar la configuración de red del invitado y adaptar las reservas de DHCP a la nueva MAC, que mencionamos de pasada. Del wiki oficial Paravirtualized Block Drivers for Windows salen la frase clave que reproducimos en su original inglés —«To switch an existing Windows installation to use the VirtIO-SCSI drivers and boot from them, it needs to see a disk requiring the driver before»—, el procedimiento del disco temporal de 1 GB con bus SCSI y controladora VirtIO en Opciones (o VirtIO Block) y la ISO de drivers con su carpeta vioscsi, el matiz de que el disco «debería conectarse en caliente; si no, hay que reiniciar la VM», el aviso sobre adaptar el orden de arranque y el plan B de volver a enganchar el disco como IDE o SATA si la VM no arranca. Que el importador de ESXi llegó con Proxmox VE 8.2, publicada el 24 de abril de 2024, y que está implementado como plugin de almacenamiento integrado en API e interfaz, procede de la nota de prensa de Proxmox sobre esa versión. La cita sobre inyectar el driver en el almacén de controladores y marcarlo para que cargue en la inicialización procede de una guía pública de croit sobre migración de VMs Windows a Proxmox VE; la reproducimos traducida y NO hemos auditado el script que propone, cosa que decimos en el propio texto. Las citas en castellano y catalán son traducción nuestra del original inglés. La lectura de que el procedimiento oficial es una reparación por máquina y no un plan de migración, el análisis de que su coste es por máquina, secuencial y dentro de la ventana, y la tesis de que la única tarea con restricción de orden dura es la que el plan estándar coloca al final, son NUESTRAS y no de ninguna de las fuentes citadas. No damos cifras de duración por máquina porque no las tenemos medidas de forma defendible, y preferimos decirlo antes que redondear. Que operamos Proxmox VE con Ceph en producción, que trabajamos con vSphere desde versiones antiguas y con Proxmox desde ramas 3.x, que hemos migrado empresas de VMware a Proxmox y también recomendado quedarse, y que no somos resellers de ninguna de las dos plataformas, es información propia de everyWAN. Que dracut genera el initramfs en modo host-only por defecto en la familia RHEL, y las órdenes para comprobar si los módulos virtio están dentro, son comportamiento estándar de esas distribuciones; compruébalo igualmente en tu máquina antes de fiarte. Los pasos descritos no sustituyen a la comprobación en tu entorno. La fotografía de portada es «Empty server rack — IMG 3677», de Jemimus, publicada en Wikimedia Commons con licencia CC BY 2.0.