Migrar de Hyper-V a Proxmox: la guía honesta, con sus diferencias y sus trampas

Un vistazo en 33 segundos

• No todo el mundo viene de VMware: hay muchas organizaciones en Hyper-V que quieren pasar a Proxmox por coste, consolidación o soberanía.
• El núcleo técnico de la migración es convertir los discos VHDX de Hyper-V al formato que usa Proxmox (qcow2 o raw), con qemu-img.
• Las VMs Windows necesitan los drivers VirtIO en Proxmox, igual que una instalación nueva: sin ellos, arrancan mal o no ven el disco.
• Ojo a Generación 1 vs 2 de Hyper-V: la 2 usa UEFI, y en Proxmox eso significa máquina q35 + OVMF; la 1 es BIOS clásica.
• Los Integration Services de Hyper-V se sustituyen por el QEMU Guest Agent; hay que quitar unos y poner el otro.

---

Casi toda la conversación sobre migrar a Proxmox gira en torno a VMware, y con razón tras las subidas de Broadcom. Pero hay un colectivo grande y menos atendido: quienes vienen de Hyper-V. Organizaciones que virtualizaron con la solución de Microsoft —porque ya tenían Windows Server, porque «venía incluido»— y que ahora quieren salir, ya sea para reducir la dependencia del ecosistema Windows, consolidar todo en una plataforma abierta, o ganar soberanía sobre su infraestructura.

Migrar de Hyper-V a Proxmox es perfectamente viable, pero tiene sus particularidades, distintas de las de venir de VMware. El formato de disco es otro, la forma de arrancar (BIOS vs UEFI) tiene una trampa concreta, y hay componentes de integración que hay que cambiar. Este artículo es la guía honesta: qué esperar, cómo se hace el grueso del trabajo, y las trampas que conviene conocer antes de empezar en vez de descubrirlas a mitad.

Hyper-V y Proxmox no piensan igual

Antes de mover nada, conviene entender que son dos mundos con lógicas distintas, y varias diferencias tienen consecuencias prácticas en la migración:

• El formato de disco. Hyper-V usa VHDX (y el antiguo VHD). Proxmox trabaja con qcow2 (con snapshots, thin provisioning) o raw (máximo rendimiento). Migrar implica convertir los discos de un formato al otro. Es el paso central.
• El arranque: Generación 1 vs 2. En Hyper-V, una VM de Generación 1 arranca con BIOS clásica; una de Generación 2, con UEFI. Esto importa mucho en Proxmox, porque hay que replicar el mismo modo de arranque: una VM UEFI necesita en Proxmox el chipset q35 y firmware OVMF (UEFI); una BIOS, la configuración por defecto. Equivocarse aquí es la causa nº 1 de «la VM migrada no arranca».
• Los componentes de integración. Hyper-V tiene sus Integration Services dentro del huésped para integrarse con el hipervisor. Proxmox usa el QEMU Guest Agent y los drivers VirtIO. No son compatibles: hay que quitar los de Microsoft y poner los de Proxmox.
• La red. Los conmutadores virtuales de Hyper-V se reconfiguran como bridges y VLANs de Proxmox; las VMs pueden necesitar reajustar su configuración de red tras el traslado.

Ninguna de estas diferencias es un muro. Pero cada una es un paso que hay que dar conscientemente, y saltarse cualquiera da problemas.

El corazón de la migración: convertir los discos

El trabajo central es llevar los discos VHDX de Hyper-V al formato de Proxmox. La herramienta es qemu-img, que viene con Proxmox y convierte entre prácticamente todos los formatos de disco virtual:

# Convertir un disco VHDX de Hyper-V a qcow2 para Proxmox
qemu-img convert -f vhdx -O qcow2 disco-original.vhdx disco-proxmox.qcow2

# O a raw, si priorizas rendimiento sobre funciones de qcow2
qemu-img convert -f vhdx -O raw disco-original.vhdx disco-proxmox.raw

El flujo general de una VM:

1. Apaga la VM en Hyper-V (una conversión en frío es la más segura y consistente; evita mover una VM en marcha).
2. Copia el/los VHDX al nodo Proxmox.
3. Convierte con qemu-img al formato elegido.
4. Crea una VM nueva en Proxmox con las características equivalentes (CPU, RAM, y —clave— el modo de arranque correcto según fuera Generación 1 o 2), sin disco.
5. Adjunta el disco convertido a esa VM (importándolo a su almacenamiento).
6. Ajusta el arranque y enciende.

El paso 4 es donde se concentra el cuidado: una VM de Generación 2 (UEFI) que crees en Proxmox como BIOS no arrancará. Replica el firmware que tenía.

La trampa de Windows: los drivers VirtIO

Si la VM que migras es Windows —lo habitual viniendo de Hyper-V—, te espera exactamente el mismo obstáculo que en cualquier Windows sobre Proxmox: necesita los drivers VirtIO, y no los tiene, porque en Hyper-V usaba los suyos de Microsoft.

Esto genera una trampa concreta: si migras el disco y lo conectas directamente como VirtIO SCSI, Windows puede no arrancar porque no tiene el driver del disco. Hay dos formas de evitarlo:

• Preparar antes de migrar: instalar los drivers VirtIO en la VM Windows mientras todavía está en Hyper-V, para que al llegar a Proxmox ya los tenga. Es la vía más limpia si puedes.
• Arrancar primero con disco emulado: conectar el disco convertido como IDE/SATA (que Windows reconoce sin drivers), arrancar, instalar los drivers VirtIO desde la ISO, apagar, y cambiar el disco a VirtIO SCSI. Un rodeo, pero funciona.

En ambos casos, tras arrancar hay que desinstalar los Integration Services de Hyper-V (ya no sirven y pueden dar guerra) e instalar el QEMU Guest Agent para la integración con Proxmox. Y activar el agente en la configuración de la VM.

Las VMs Linux: más fáciles, pero revisa el arranque y la red

Las máquinas Linux suelen migrar con menos fricción, porque los kernels modernos ya traen soporte VirtIO de fábrica. Aun así, conviene revisar:

• El modo de arranque (BIOS vs UEFI), igual que en Windows: que coincida con lo que tenía.
• La configuración de red: los nombres de interfaz pueden cambiar al pasar de la red de Hyper-V a la de Proxmox, y una VM que espera eth0 y se encuentra otro nombre se queda sin red. Revisa la configuración de red tras el primer arranque.
• El fstab y los identificadores de disco: si la VM monta discos por identificadores que cambian, ajústalos.
• Instala el QEMU Guest Agent de Linux para la integración.

Un plan realista

Sin sorpresas, el orden que funciona:

1. Inventario y priorización: qué VMs, cuáles son Generación 1 o 2, cuáles Windows o Linux, cuáles críticas. Empieza por una no crítica para rodar el proceso.
2. Prepara los drivers en las VMs Windows (instala VirtIO antes de migrar, si puedes).
3. Ventana de mantenimiento y backup de la VM en origen antes de tocarla.
4. Apaga, copia, convierte el disco con qemu-img.
5. Crea la VM en Proxmox con el arranque correcto y adjunta el disco.
6. Arranca, ajusta (drivers, guest agent, red), valida que rinde y que sus servicios funcionan.
7. Repite, afinando el proceso con cada VM, y deja las críticas para cuando el procedimiento esté rodado.

Como en toda migración, el grueso del coste no está en convertir el disco —eso es un comando— sino en la validación y en resolver los casos particulares. Presupuesta tiempo para probar, no solo para mover. Y si el parque es grande, considera apoyarte en quien ya ha hecho el camino.

Preguntas frecuentes

¿Se puede migrar de Hyper-V a Proxmox? Sí, perfectamente. El núcleo es convertir los discos VHDX de Hyper-V al formato de Proxmox (qcow2 o raw) con qemu-img, crear una VM equivalente en Proxmox con el modo de arranque correcto, y ajustar drivers y componentes de integración. Es viable tanto para VMs Windows como Linux, con sus particularidades cada una.

¿Cómo convierto un disco VHDX a Proxmox? Con qemu-img convert, que viene con Proxmox: qemu-img convert -f vhdx -O qcow2 origen.vhdx destino.qcow2 (o -O raw para máximo rendimiento). Luego se importa ese disco a una VM nueva de Proxmox. Conviene hacer la conversión con la VM apagada (en frío) para que sea consistente.

¿Por qué mi VM Windows migrada no arranca? Casi siempre por una de dos razones: el modo de arranque no coincide (una VM de Generación 2 de Hyper-V es UEFI y en Proxmox necesita q35 + OVMF; si la creaste como BIOS, no arranca), o Windows no tiene el driver VirtIO del disco. Para lo segundo, arranca primero con disco emulado IDE/SATA, instala los drivers VirtIO, y luego cambia a VirtIO SCSI.

¿Qué pasa con los Integration Services de Hyper-V? No sirven en Proxmox y conviene desinstalarlos tras migrar, porque pueden dar problemas. Se sustituyen por el QEMU Guest Agent (y los drivers VirtIO), que proporcionan la integración equivalente con Proxmox: apagado limpio, backups consistentes, etc.

¿Es más difícil que migrar desde VMware? No necesariamente, es distinto. VMware tiene herramientas de importación muy pulidas; Hyper-V pasa más por la conversión manual de discos con qemu-img. Las trampas propias de Hyper-V son el modo de arranque (Generación 1 vs 2) y los drivers en Windows. Con el proceso claro, es igual de asumible; el grueso del esfuerzo está en la validación, como en toda migración.

Fuentes

• Proxmox, documentación de migración a Proxmox VE.
• QEMU, documentación de qemu-img y formatos de disco soportados.
• Proxmox, drivers VirtIO para Windows.
• Proxmox, QEMU Guest Agent.
• Microsoft, documentación sobre generaciones de máquinas virtuales de Hyper-V (BIOS vs UEFI).

---

¿Quieres salir de Hyper-V y consolidar en un cloud privado abierto sobre Proxmox? Te ayudamos a planificar y ejecutar la migración —conversión de discos, drivers, validación— sin sorpresas. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.