Problema

Los administradores que gestionan entornos mixtos suelen encontrarse con la necesidad de mover máquinas virtuales (VM) de Hyper‑V a Proxmox VE. A diferencia de VMware ESXi, Proxmox no incluye un asistente automático para esta tarea, lo que obliga a un proceso manual que combina exportación de discos, conversión de formatos y ajustes de controladores. El error más frecuente es un arranque fallido después de conectar el disco convertido directamente a un controlador SCSI, lo que genera pantallas azules (BSOD) en Windows o bucles de reinicio en Linux. El patrón típico es: exportar VHDX → convertir a QCOW2 → crear VM en Proxmox → intentar arranque → falla por controladores ausentes.

Causa

  1. Controladores de disco ausentes
    Hyper‑V usa controladores IDE o SCSI nativos. Cuando la VM se traslada a Proxmox y se conecta a un controlador VirtIO SCSI sin que el sistema operativo tenga los drivers instalados, el hipervisor no puede acceder al disco en el primer arranque.

  2. QEMU Guest Agent y VirtIO no presentes
    Sin el agente y los drivers VirtIO, la VM no reconoce la interfaz de red ni el disco optimizado, lo que provoca latencias y, en algunos casos, bloqueos del kernel.

  3. Conversión de disco con preasignación incorrecta
    Usar qemu-img convert sin la opción de thin provisioning puede inflar el tamaño del archivo y agotar el espacio del datastore, provocando errores de I/O durante el arranque.

  4. Orden de arranque incorrecto
    Proxmox asigna por defecto el disco convertido a SCSI. Windows necesita arrancar una vez desde IDE/SATA para cargar los drivers SCSI antes de poder usar el controlador VirtIO.

Solución

Una estrategia reutilizable consta de cuatro fases: preparación del guest, exportación y conversión del disco, creación de la VM en Proxmox y ajuste del orden de arranque.

1. Preparar el sistema operativo

  • Instalar drivers VirtIO
    Descarga el paquete ISO de drivers VirtIO desde el repositorio oficial de Fedora. Monta la ISO dentro de la VM Hyper‑V y ejecuta los instaladores de:

    • viostor (controlador de disco)
    • netkvm (controlador de red)
    • qemu-ga (QEMU Guest Agent)

  • Reiniciar para que Windows registre los nuevos controladores. En Linux basta con instalar virtio-modules y qemu-guest-agent mediante el gestor de paquetes.

2. Exportar y convertir el disco

  1. En Hyper‑V, apaga la VM y exporta el disco VHDX a un almacenamiento accesible desde el nodo Proxmox.
  2. En el nodo Proxmox, ejecuta qemu-img convert con thin provisioning:
qemu-img convert -f vhdx -O qcow2 -o preallocation=off /ruta/origen/disk.vhdx /var/lib/vz/images/VMID/vm-VMID-disk-0.qcow2
  • -f vhdx indica el formato de origen.
  • -O qcow2 define el formato destino.
  • preallocation=off mantiene el archivo en modo thin, ahorrando espacio.

3. Crear la VM en Proxmox

  • Usa la GUI o la CLI para crear una VM con la misma cantidad de vCPU y RAM que la original.
  • En la sección de hardware, añade primero un controlador IDE o SATA y asigna el disco QCOW2 recién convertido a ese controlador.
  • Añade un controlador VirtIO SCSI (pero sin conectar el disco todavía) y una interfaz de red VirtIO.

4. Arranque inicial y migración del disco

  1. Arranca la VM. Debería iniciar sin problemas porque el disco está bajo IDE/SATA.
  2. Dentro del OS, verifica que el controlador VirtIO SCSI está presente en el Administrador de dispositivos (Windows) o que el módulo virtio_scsi está cargado (Linux).
  3. Apaga la VM, vuelve a la configuración de Proxmox y desasigna el disco del controlador IDE/SATA y asígnalo al controlador VirtIO SCSI.
  4. Reinicia. El sistema ahora debería arrancar usando el controlador SCSI optimizado, con acceso a la red VirtIO y al Guest Agent.

Cuándo aplicar esta solución

  • Entornos mixtos donde se necesite migrar VMs Windows o Linux desde Hyper‑V a Proxmox sin herramientas de terceros.
  • Escenarios de prueba o laboratorios donde la cantidad de VMs es manejable manualmente (decenas, no cientos).
  • Situaciones donde la VM original tiene drivers VirtIO instalados o se puede instalar antes de la exportación.

No es adecuada cuando:

  • Se requiere migrar cientos de VMs simultáneamente; en ese caso, una solución de scripting masivo o herramienta comercial será más eficiente.
  • La VM depende de hardware propietario no soportado por VirtIO (por ejemplo, tarjetas de video passtrough específicas).

Código

# Paso 1: convertir VHDX a QCOW2 (thin provisioning)
qemu-img convert -f vhdx -O qcow2 -o preallocation=off /mnt/hyperv_exports/vm1.vhdx /var/lib/vz/images/101/vm-101-disk-0.qcow2

# Paso 2: crear VM (CLI) con IDE y SCSI preparados
qm create 101 --name vm1 --memory 4096 --cores 2
qm set 101 --ide0 local:101/vm-101-disk-0.qcow2,media=disk
qm set 101 --scsihw virtio-scsi-pci
qm set 101 --net0 virtio,bridge=vmbr0
qm set 101 --boot order=ide0

# Después del primer arranque exitoso, mover disco a SCSI
qm set 101 --ide0 none
qm set 101 --scsi0 local:101/vm-101-disk-0.qcow2
qm set 101 --boot order=scsi0

Verificación

  1. Primer arranque (IDE)

    • La pantalla de inicio de Windows o el login de Linux aparecen sin errores.
    • Device Manager muestra el controlador VirtIO SCSI como “funcionando correctamente” (Windows).
    • En Linux, lsblk -d -o NAME,TRAN muestra sda con virtio.

  2. Segundo arranque (SCSI)

    • Apaga la VM, cambia el disco a SCSI y reinicia.
    • El sistema arranca sin BSOD ni kernel panic.
    • La interfaz de red VirtIO obtiene una dirección IP y qemu-ga responde a qm agent ping 101.

  3. Comprobación de rendimiento

    • Ejecuta fio o dd para validar que el I/O está bajo el controlador VirtIO y no bajo emulación IDE.
    • En Windows, abre el Task Manager → Performance y verifica que el disco aparece como “VirtIO”.

Notas adicionales

  • Snapshots: antes de iniciar la migración, crea un snapshot de la VM en Hyper‑V. Permite volver atrás rápidamente si la instalación de drivers falla.
  • Drivers de SCSI: en versiones de Windows Server 2012 y posteriores, el driver vioscsi ya está incluido, pero sigue siendo buena práctica instalar el paquete más reciente desde la ISO VirtIO.
  • Espacio en disco: aunque preallocation=off ahorra espacio, el archivo QCOW2 sigue creciendo de forma dinámica. Monitorea el datastore para evitar sorpresas.
  • Automatización: los bloques de qm set pueden envolver en un script Bash que recorra una lista de VMIDs, lo que simplifica migraciones por lotes.
  • Redes: si la VM usa VLANs o bonding, replica la configuración en la interfaz VirtIO antes del primer arranque para evitar pérdida de conectividad.
  • QEMU Guest Agent: habilitarlo mejora la gestión de la VM desde la UI de Proxmox (shutdown limpio, backups consistentes). No olvides habilitar el servicio dentro del guest (systemctl enable qemu-ga en Linux o el servicio correspondiente en Windows).