Problema

Muchas organizaciones escolares y medianas están dejando Hyper‑V para adoptar Proxmox VE por su modelo de código abierto y la flexibilidad de LXC/KVM. El reto no es solo “instalar Proxmox”, sino trasladar cientos de VMs, cambiar controladores de disco, migrar servicios críticos (AD, DNS, DHCP) a Linux y mantener la disponibilidad de almacenamiento iSCSI y la red de clúster. Cuando la infraestructura incluye varios hosts, enlaces LACP y backup externo, los errores aparecen en la conversión de discos, en la sincronización de AD con Samba y en la configuración de corosync sobre VLAN compartida. El objetivo es una migración ordenada que evite caídas de servicios y pérdida de datos.

Causa

  1. Conversión de discos – Hyper‑V usa VHDX con controladores virtIO‑SCSI. Proxmox requiere qcow2 o raw y necesita que los drivers virtIO estén presentes antes del primer arranque. Si el driver no está instalado, Windows arranca en modo “BSOD” o con rendimiento degradado.
  2. AD en Samba 4 – Samba puede actuar como DC, pero la replicación con controladores Windows exige que el esquema esté alineado y que el reloj del clúster sea preciso. Un desfase de segundos rompe la sincronización y genera errores de Kerberos.
  3. iSCSI desde QNAP – Proxmox accede a LUNs a través del initiator open‑iscsi. En RAID5 SSD la latencia es baja, pero la configuración de multipath y el uso de LACP pueden generar “path flaps” si la VLAN no está aislada correctamente.
  4. Corosync sobre LACP – Compartir la misma interfaz física con tráfico de VM y de clúster es posible, pero la congestión o la pérdida de paquetes en la unión LACP pueden provocar split‑brain.
  5. Backup PBS vs Veeam – PBS usa snapshots de QEMU y depende de VSS para Windows. Si el agente VSS no está instalado o la política de snapshot no está afinada, los backups no son consistentes.
  6. Hardware legado (Xeon E5‑2640, Gen 8) – El soporte de KVM está presente, pero algunos microcódigos de BIOS antiguos limitan VT‑d o la capacidad de pasar dispositivos PCIe a VMs.

Solución

1. Preparar los hosts y la red

  • Actualizar BIOS a la última versión disponible y habilitar VT‑x/VT‑d.
  • Crear dos puentes de Linux: vmbr0 (trunk de VM) y vmbr1 (corosync + iSCSI). Asignar la LACP a bond0 y marcar la VLAN de corosync como “priority‑tagged”.
  • En el switch Juniper, confirmar que el LACP está en modo “active” y que el número de puertos coincide con los de los hosts.

2. Convertir VHDX → qcow2 con drivers VirtIO

  1. Instalar los drivers en la VM Hyper‑V
    • Montar el ISO “virtio-win‑latest.iso”.
    • En el Administrador de dispositivos, actualizar “SCSI controller” y “Network adapter” a los controladores “Red Hat VirtIO”.
  2. Exportar el VHDX
    • Detener la VM y copiar el archivo VHDX a un storage accesible desde el nodo Proxmox.
  3. Ejecutar qemu‑img
qemu-img convert -f vhdx -O qcow2 /mnt/hyperv/vm01.vhdx /var/lib/vz/images/101/vm01.qcow2
  1. Crear la VM en Proxmox
    • Usar qm create 101 --name vm01 --memory 8192 --net0 virtio,bridge=vmbr0.
    • Añadir el disco con qm set 101 --scsi0 local:101/vm01.qcow2.
    • Configurar el disco de arranque bootdisk=scsi0.

3. Implementar Samba 4 como DC

  • Instalar samba-ad-dc en Ubuntu 24.04 y ejecutar samba-tool domain provision --use-rfc2307 --realm=EXAMPLE.COM --domain=EXAMPLE.
  • Unir los controladores Windows existentes con samba-tool domain join.
  • Configurar krb5.conf y nsswitch.conf para que los clientes Linux usen el nuevo DC.
  • Habilitar dns forwarder = 8.8.8.8 en smb.conf para resolver internet.
  • Verificar replicación con samba-tool drs showrepl.

4. iSCSI y multipath en Proxmox

  • Instalar open-iscsi y multipath-tools.
  • Añadir el target en /etc/iscsi/initiatorname.iscsi y ejecutar iscsiadm -m discovery -t sendtargets -p 10.0.0.10.
  • Activar multipath con multipath -F && multipath.
  • En Proxmox, crear un “LVM over iSCSI” storage y asignar los LUNs a los nodos del clúster.

5. Corosync sobre LACP

  • En /etc/pve/corosync.conf usar la interfaz vmbr1 y especificar bindnetaddr: 10.0.10.0.
  • Añadir transport: knet y definir los “link‑number” para cada NIC del bond.
  • Probar la latencia con corosync-cfgtool -s.

6. PBS vs Veeam

  • Instalar proxmox-backup-server en una VM dedicada.
  • En cada nodo Proxmox, registrar el datastore PBS (pveam update && pveam available).
  • Para Windows, instalar el agente vssvc desde el paquete proxmox-backup-client.
  • Crear una tarea de backup con snapshot y prune-schedule para retener 7 diarios, 4 semanales y 12 mensuales.

7. Orden de migración

  1. Linux VMs – Mover primero los servicios de monitoreo, UniFi, Home Assistant. Son los menos críticos y prueban la conectividad iSCSI y la red.
  2. Samba DC – Levantar el primer DC en Ubuntu, validar replicación, luego despromover uno de los controladores Windows.
  3. Windows VMs con drivers VirtIO – Migrar los que no dependen de VSS (por ejemplo, POS) antes de los que sí (FileMaker, Veeam).
  4. Servicios críticos con VSS – Configurar el agente VSS y ejecutar una prueba de backup antes de moverlos.
  5. Servicios legacy (Avaya, etc.) – Mantener en Hyper‑V hasta que la sustitución esté lista.

Cuándo aplicar esta solución

  • Entornos mixtos con al menos 10 VMs Windows y varios Linux.
  • Almacenamiento iSCSI gestionado por QNAP o similar y necesidad de alta disponibilidad.
  • Requerimiento de AD sin depender exclusivamente de Windows Server.
  • Hardware de generación Sandy Bridge donde la virtualización ya está soportada pero necesita ajustes de BIOS.

No es adecuada si:

  • Solo se usan VMs Linux y no hay dependencia de AD.
  • El storage es NFS o Ceph; la sección iSCSI no aplicaría.
  • Se planea migrar a una nube pública en vez de mantener on‑premise.

Código

# 1. Convertir VHDX a qcow2
qemu-img convert -f vhdx -O qcow2 /mnt/hyperv/vm01.vhdx /var/lib/vz/images/101/vm01.qcow2

# 2. Descubrir iSCSI targets y habilitar multipath
iscsiadm -m discovery -t sendtargets -p 10.0.0.10
systemctl restart iscsid
multipath -F && multipath

# 3. Añadir nodo al clúster Proxmox
pvecm add 10.0.1.5 --force

# 4. Crear tarea PBS para Windows VM 101
proxmox-backup-client backup VM101 --repository proxmox:backup --snapshot --compress zstd

Verificación

  1. Arranque de VM – Verificar que Windows arranca sin BSOD y que el adaptador de red muestra “VirtIO”.
  2. Replicación Samba – Ejecutar samba-tool drs showrepl y confirmar que todos los DC aparecen con “OK”.
  3. Latencia iSCSI – Medir IOPS con fio --name=randread --ioengine=libaio --rw=randread --bs=4k --size=1G --numjobs=4 --runtime=60 --group_reporting.
  4. Corosync health – corosync-cfgtool -s debe listar todos los nodos sin “offline”.
  5. Backup PBS – Restaurar una VM de prueba y comprobar que los archivos están consistentes (especialmente bases de datos de FileMaker).

Notas adicionales

  • En entornos con terremotos, considera habilitar write cache=write back en los SSD y usar mdadm con RAID10 en vez de RAID5 para mayor tolerancia a fallos.
  • Si el switch Juniper tiene “storm control” activado, desactívalo en los puertos de LACP; de lo contrario, el tráfico de VM puede ser limitado y afectar la migración en vivo.
  • Para evitar “split‑brain” en corosync, configura quorum.device con un “qdevice” externo (por ejemplo, un nodo de gestión) cuando el número de nodos sea impar.
  • Cuando uses PBS con VSS, revisa que la política de “snapshot‑mode” sea snapshot y no `