Por qué las VMs de Windows no arrancan al migrar de VMware a Proxmox VE

Dejar VMware resultó ser la decisión fácil.

El caos de las licencias hizo que esa parte fuera casi emocional. Te sientas en una reunión, miras una hoja de cálculo y de repente los números ya no cuadran. Así que haces lo que muchos equipos de infraestructura han estado haciendo últimamente: eliges Proxmox, esbozas un plan de migración y te dices que básicamente es un problema de V2V con un logo distinto en la interfaz.

Esa confianza dura justo hasta que tu primera VM de Windows arranca... y se estrella de inmediato en una pantalla azul, una y otra vez.

Esta historia tiene poco que ver con que Proxmox sea "malo" o Windows "terrible" (aunque Windows a veces se gane esa reputación). Tiene que ver con suposiciones, instintos formados en VMware y un puñado de detalles que la mayoría de las guías de migración pasan por alto cortésmente porque son engorrosos, poco atractivos y muy capaces de arruinarte el fin de semana.

Tu modelo mental de VMware es el problema

Si has vivido en el mundo de VMware durante años, tu cerebro está programado de cierta forma. Las controladoras de almacenamiento parecen abstraídas y las migraciones parecen transaccionales: mueves bits, enciendes la máquina y sigues adelante.

Proxmox no juega a eso. Por debajo, es abiertamente Linux y KVM, y muy explícito sobre cómo se presenta el hardware a los invitados. Eso es bueno, ya que es rápido, flexible y transparente. Pero también significa que Windows de pronto es muy consciente de desde dónde está arrancando, y no le gustan las sorpresas.

Las VMs de Linux apenas pestañean. La mayoría de las nuestras arrancaron al primer intento, se quejaron un poco de las interfaces de red y continuaron con su día. Windows, sobre todo las versiones más antiguas, reacciona más como si le hubieras cambiado el motor al coche mientras iba por la autopista.

La primera trampa: redes de clúster que casi funcionan

Antes de llegar a las pantallas azules, hay un error de red que sigue apareciendo en los análisis posteriores a incidentes.

Sobre el papel, un enlace compartido de 10GbE parece generoso, con bastante ancho de banda y margen. ¿Por qué no dejar que el tráfico del clúster, la gestión y las migraciones vayan todos juntos para el movimiento inicial?

Porque los clústeres de Proxmox funcionan sobre Corosync, y a Corosync le importa la latencia mucho más que el ancho de banda. No le gusta nada que la latencia se dispare de golpe porque decidiste saturar el enlace con una migración de varios terabytes.

Lo que ocurre después parece dramático si no te lo esperas. Los nodos empiezan a perder latidos (heartbeats), el clúster asume que algo va mal, entra en juego el fencing y las máquinas se reinician solas porque creen que han quedado aisladas. Desde fuera, parece que Proxmox ha entrado en pánico. En realidad, está haciendo exactamente aquello para lo que fue diseñado.

La solución no tiene misterio. Separa físicamente el tráfico o, como mínimo, coloca las migraciones en su propia VLAN con aislamiento real. En cuanto dejamos de enviar datos por la misma ruta que el heartbeat, los reinicios aleatorios desaparecieron.

Lección aprendida: cuando hay clústeres de por medio, trata lo "recomendado" de la documentación como obligatorio.

Luego vino Windows y el bucle de BSOD

Esta es la parte de la que todo el mundo habla en voz baja. Importas una VM de Windows, haces clic en Start, la pantalla de arranque parpadea y de repente te encuentras con INACCESSIBLE_BOOT_DEVICE.

El motivo es dolorosamente simple una vez que lo ves. VMware presenta el almacenamiento usando controladoras desde las que Windows ya sabe arrancar. Proxmox no. Espera que uses VirtIO por rendimiento, y Windows se negará en rotundo a arrancar desde una controladora que no haya marcado como crítica para el arranque.

La trampa es que instalar los controladores no basta. Puedes ejecutar el instalador de VirtIO todo el día, pero si Windows nunca ve un disco VirtIO mientras está en ejecución, a menudo no marcará el controlador para que cargue durante la fase de arranque. Tras la migración, Windows despierta, busca la controladora antigua, no la encuentra, se rinde y vuelves a la pantalla azul.

El truco simple que de verdad funciona

La solución más fiable acabó siendo poco elegante, algo absurda y completamente determinante.

Antes de la migración, añade un pequeño disco ficticio a la VM usando una controladora VirtIO SCSI. Un gigabyte es más que suficiente, porque lo que importa es la controladora y el disco es irrelevante.

Ese único paso obliga a Windows a enumerar el hardware, cargar el controlador y marcarlo como obligatorio en el arranque, de modo que el controlador queda validado además de instalado. Tras la migración, Windows arranca sin problemas porque ya sabe qué está viendo.

En internet la gente discute sobre DISM, inyección de registro fuera de línea, scripts para el almacén de controladores y toda clase de automatizaciones ingeniosas. Parte de eso funciona la mayoría de las veces. Esto funciona casi siempre, sobre todo en compilaciones antiguas de Windows Server que llevan años acumulando parches y actualizaciones.

Es feo y aburrido, pero ahorra horas de trabajo.

Por qué el asistente de importación no hace magia

El asistente de importación nativo de Proxmox es francamente bueno. Para VMs pequeñas o medianas, la experiencia es casi de un solo clic, y los servidores web, nodos de aplicaciones y equipos auxiliares se migran sin dramas.

El problema empieza cuando los discos se hacen grandes. Muy grandes. En cuanto cruzas al terreno de los múltiples terabytes, sobre todo con archivos VMDK dinámicos que respaldan bases de datos, el asistente se vuelve lentísimo, perdiendo el tiempo traduciendo espacio vacío que nadie necesita realmente.

Ahí es donde ganan las herramientas de la vieja escuela. Para los sistemas más grandes, nos desconectamos y usamos Clonezilla para copiar únicamente los bloques ocupados. En el mismo enlace de 10GbE, la experiencia fue radicalmente distinta, con menos esperas y menos sorpresas.

Otros prefieren Veeam para este paso, especialmente si ya está presente en el entorno. Sea cual sea la herramienta que elijas, la habilidad consiste en saber cuándo la interfaz reluciente deja de ser tu amiga.

Las migraciones de Windows son más que mover datos

Este es el cambio de mentalidad más importante. Mover Windows entre hipervisores implica cambiar hardware virtual de maneras que Windows nota por completo, además de copiar discos: controladoras de almacenamiento, orden de arranque, tiempos de carga de controladores y marcas en el registro en las que nunca piensas hasta que lo rompen todo.

VMware aisló a los administradores de la mayor parte de eso durante años. Proxmox no lo hace, y yo no llamaría a eso un defecto. Solo significa que la fase de migración exige más respeto.

Una vez que Windows está levantado y estable en Proxmox, funciona de forma sólida. El rendimiento es excelente y VirtIO destaca. Los problemas se concentran al principio, en la ventana de cambio definitivo, donde cada fallo parece más ruidoso y estresante de lo que debería.

El alivio de un primer arranque limpio

Hay un momento concreto durante estas migraciones que se te queda grabado. Haces clic en Start, se abre la consola, aparece el logo de Windows y los puntos giratorios siguen dando vueltas. No hay pantalla azul ni reinicio automático. Al final, aparece la pantalla de inicio de sesión como si nada dramático hubiera pasado, y es ahí cuando por fin respiras.

En ese punto, eliminar VMware Tools, limpiar dispositivos y ajustar el rendimiento resulta rutinario. Lo difícil ya ha quedado atrás.

Proxmox es más transparente con el hardware

Dejar atrás VMware no es el reto técnico que la gente cree. Lo difícil es desaprender hábitos que VMware hacía parecer seguros.

Proxmox expone la realidad. Los clústeres necesitan enlaces de baja latencia, Windows necesita ver su controladora de arranque antes de aceptar confiar en ella y los discos grandes necesitan la herramienta de migración adecuada. Nada de eso tiene misterio. Solo es fácil de subestimar hasta que te quedas mirando una pantalla azul a las 2 a.m.

Si te quedas con una sola lección, que sea planificar Windows primero y tratarlo como el invitado frágil y testarudo que es. Hazlo, y el resto de la migración dará mucho menos miedo.

Y una vez que estés en el otro lado, puede que te des cuenta de que la parte más difícil de dejar VMware era convencer a Windows de subirse al viaje.