Problema

Muchas organizaciones gestionan cientos de servidores con VMware ESXi instalados en medios de arranque reducidos (SD, USB) y almacenan sus máquinas virtuales en arrays locales RAID. Cuando el coste del licenciamiento o la necesidad de una plataforma más abierta se vuelve crítico, surge la necesidad de migrar esas VMs a Proxmox VE. El reto típico es hacerlo sin añadir hardware temporal, sin acceso físico y manteniendo una vía de reversión que permita volver a ESXi en minutos si algo falla. Además, la migración debe ejecutarse en ventanas de mantenimiento nocturnas, usando únicamente la infraestructura existente (NAS de backups, red corporativa y los propios hosts).

Causa

  1. Dependencia del arranque local – ESXi en tarjetas SD impide arrancar un hipervisor alternativo en el mismo nodo sin re‑flashear.
  2. Almacenamiento local RAID5 – Los discos están configurados como un único datastore; moverlos a otro hipervisor requiere copiar o convertir los discos virtuales.
  3. Ausencia de host de salto – No hay un servidor intermedio disponible para alojar herramientas de conversión o para actuar como proxy Veeam.
  4. Necesidad de rollback rápido – En entornos con pocos VMs por host, cualquier error que impida el arranque de una VM afecta a los servicios críticos, por lo que la reversión debe ser casi instantánea.
  5. Backups centralizados en NAS – La única copia fiable de los datos está en un NAS accesible por red; cualquier proceso de migración debe aprovechar ese punto de restauración.

Solución

1. Preparar Proxmox en el mismo nodo

  • Re‑flashear la SD con la ISO de Proxmox VE (compatible con el hardware Dell R440).
  • Configurar la red idéntica a la de ESXi (mismo VLAN, IP estática o DHCP según política).
  • Crear un storage local (por ejemplo, local-lvm) y un storage NFS apuntando al NAS de backups. El NFS será el punto de entrada para los archivos VMDK/OVF.

No es necesario provisionar un segundo servidor; el propio nodo será el destino y el origen de la migración.

2. Exportar VMs desde Veeam

Veeam Backup & Replication permite “Restore to Hypervisor” directamente a Proxmox, pero requiere un proxy que pueda montar el datastore de destino. La forma más ligera es crear una VM temporal en Proxmox (Ubuntu Server 22.04, 2 vCPU, 2 GB RAM) y usarla como proxy.

Pasos:

  1. En Veeam, crear un Backup Copy Job que mantenga la última copia en el NAS.
  2. Seleccionar la VM, elegir Restore to → Hypervisor → Proxmox (seleccionar la IP del proxy).
  3. Veeam enviará los discos VMDK al proxy y los depositará en el share NFS configurado.

3. Convertir discos VMDK a formato QCOW2 o RAW

Si se prefiere evitar el proxy, se pueden descargar los VMDK al NAS y convertirlos directamente en Proxmox:

# Montar el share NFS (asumiendo /mnt/backup)
mount -t nfs nas_ip:/export/veeam /mnt/backup

# Convertir VMDK a RAW (más rápido para importdisk)
qemu-img convert -f vmdk -O raw /mnt/backup/vm_101.vmdk /var/lib/vz/images/101/vm-101-disk-0.raw

4. Importar discos a Proxmox

Con el disco ya en RAW (o QCOW2) usar qm importdisk para crear el disco virtual en el storage deseado:

qm create 101 --name vm101 --memory 4096 --net0 virtio,bridge=vmbr0
qm importdisk 101 /var/lib/vz/images/101/vm-101-disk-0.raw local-lvm
qm set 101 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-101-disk-0
qm set 101 --boot c --bootdisk scsi0

5. Ajustes post‑importación

  • Verificar que la controladora de disco coincida con la que usaba la VM en ESXi (por lo general lsilogic → virtio-scsi).
  • Adaptar la configuración de red (MAC, VLAN) para que la VM recupere su dirección IP sin conflicto.
  • Instalar los drivers de virtio dentro del SO invitado si aún no están presentes (Linux suele detectarlos automáticamente; Windows necesita los drivers de la ISO de Proxmox).

6. Prueba y validación

Arrancar la VM en Proxmox, comprobar logs, conectividad y rendimiento. Si todo funciona, marcar la VM como productiva y proceder con la siguiente.

7. Estrategia de rollback

  • Mantener la SD de ESXi intacta: antes de flashear, crear una copia de la tarjeta SD (por ejemplo, usando dd a una imagen en el NAS). En caso de fallo, restaurar la imagen y volver a arrancar ESXi en segundos.
  • Snapshots de Proxmox: antes de iniciar la VM, crear un snapshot (qm snapshot 101 pre‑test). Si la VM no arranca, revertir al snapshot y, si el problema persiste, volver a ESXi.
  • Backup de Veeam: la copia en el NAS sigue siendo la fuente de verdad; se puede restaurar la VM directamente a ESXi usando la misma funcionalidad “Restore to Hypervisor”.

8. Automatización opcional

Para cientos de nodos, envolver los pasos anteriores en un script Ansible o Terraform que:

  • Despliegue Proxmox en la SD.
  • Monte el NFS y ejecute qemu-img y qm importdisk.
  • Registre resultados en un inventario central.

Esto reduce el tiempo de ventana de mantenimiento a minutos por nodo.

Cuándo aplicar esta solución

  • Entornos con pocos VMs por host (1‑4) donde el tiempo de inactividad es crítico.
  • Infraestructura sin host de salto: la solución usa una VM ligera como proxy o la propia conversión en el nodo.
  • Backups centralizados en NAS y disponibilidad de Veeam o de los archivos VMDK.
  • Necesidad de rollback inmediato: la copia de la SD y los snapshots garantizan una reversión en menos de 5 minutos.

No es adecuada cuando:

  • Los discos están en SAN con LUNs exclusivas de ESXi (requiere acceso a la SAN desde Proxmox).
  • Se necesita migrar cientos de VMs simultáneamente; la conversión manual se vuelve impráctica y conviene usar herramientas de replicación en tiempo real.
  • El hardware no soporta arranque desde USB/SD con Proxmox (aunque la mayoría de servidores Dell R440 sí lo hacen).

Código

# Montar NFS del NAS
mount -t nfs 10.0.0.20:/veeam_backups /mnt/backup

# Convertir VMDK a RAW
qemu-img convert -f vmdk -O raw /mnt/backup/vm_202.vmdk /var/lib/vz/images/202/vm-202-disk-0.raw

# Crear VM en Proxmox
qm create 202 --name web01 --memory 8192 --net0 virtio,bridge=vmbr0

# Importar disco RAW al storage local-lvm
qm importdisk 202 /var/lib/vz/images/202/vm-202-disk-0.raw local-lvm

# Asignar disco y configurar arranque
qm set 202 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-202-disk-0
qm set 202 --boot c --bootdisk scsi0

# Crear snapshot antes de pruebas
qm snapshot 202 pre-test

Verificación

  1. Estado del VM: qm status 202 debe devolver running.
  2. Conectividad: ping a la IP esperada, comprobar rutas y firewall.
  3. Integridad de discos: comparar hashes del archivo RAW con el VMDK original (sha256sum).
  4. Logs del SO invitado: revisar dmesg y journalctl para errores de controlador virtio.
  5. Prueba de carga: ejecutar una carga representativa (por ejemplo, una petición HTTP) y medir latencia.

Si cualquiera de los puntos falla, revertir al snapshot (qm rollback 202 pre-test) o restaurar la SD de ESXi y volver a arrancar el nodo.

Notas adicionales

  • RAID5 en producción es vulnerable a una segunda falla de disco; asegúrese de que los backups estén al día antes de iniciar la migración.
  • Ancho de banda entre el NAS y los nodos puede ser el cuello de botella; programe la copia de discos fuera de horas pico.
  • Drivers virtio: para Windows, montar la ISO de Proxmox (/usr/share/pve-manager/iso/virtio-win.iso) y ejecutar el instalador de drivers antes del primer arranque.
  • Licenciamiento Veeam: la funcionalidad “Restore to Hypervisor” está disponible