Cómo Migramos +500 VMs de VMware a Proxmox Sin Parar el Negocio

Uno de nuestros clientes se encontró con que su factura de VMware pasaba de 80.000€ a 350.000€ anuales tras la adquisición de Broadcom. Tenía 12 hosts ESXi, más de 500 máquinas virtuales y tres sedes. Necesitaba una alternativa real, sin parar el negocio. Esto es lo que hicimos.

El contexto: cuando VMware deja de ser una opción

El cliente es una empresa industrial con presencia en tres sedes en Cataluña. Su entorno de virtualización llevaba siete años sobre VMware vSphere con vSAN: 12 hosts ESXi, más de 500 VMs en producción, redes VLAN segmentadas por departamento y réplicas entre sedes. Todo funcionaba. Hasta que llegó la factura de renovación.

Con el cambio de modelo de licencias de Broadcom, el coste pasaba de 80.000€ a 350.000€ anuales — un incremento del 337%. No era un error: era el nuevo precio. El cliente nos llamó con una pregunta clara: «¿Podemos salir de VMware sin parar el negocio?»

Fase 1: Auditoría completa (semanas 1-2)

Antes de tocar nada, necesitábamos saber exactamente qué teníamos. Hicimos un inventario exhaustivo de todo el entorno VMware con RVTools, scripts PowerCLI personalizados y documentación manual de dependencias.

# Inventario automatizado con PowerCLI
Get-VM | Select Name, PowerState, NumCpu, MemoryGB, `
  @{N='DiskGB';E={(Get-HardDisk -VM $_ | Measure -Sum CapacityGB).Sum}}, `
  @{N='VLAN';E={(Get-NetworkAdapter -VM $_ ).NetworkName}}, `
  Guest, VMHost | Export-Csv -Path vm_inventory.csv

# Resultado: 512 VMs, 14.3 TB de disco, 47 VLANs unicas

La auditoría reveló sorpresas. Encontramos 47 máquinas con Windows Server 2012 R2 que nadie recordaba que existían, algunas corriendo servicios de ficheros antiguos que todavía tenían usuarios activos. También descubrimos 23 snapshots huérfanos que consumían 2.1 TB de espacio innecesario.

Fase 2: Diseño del nuevo entorno (semanas 2-3)

Diseñamos un cluster Proxmox VE de 12 nodos (reutilizando el mismo hardware) con Ceph como storage distribuido. La clave era replicar exactamente la topología de red existente para que las aplicaciones no notaran ningún cambio.

Fase 3: Piloto con 30 VMs (semanas 3-4)

No migramos todo de golpe. Seleccionamos 30 VMs no críticas — entornos de desarrollo, servidores de test y herramientas internas — para validar todo el proceso. La conversión VMDK a QCOW2 fue el núcleo técnico:

# Conversion VMDK -> QCOW2 con compresion
qemu-img convert -f vmdk -O qcow2 -o preallocation=metadata \
  vm-disk.vmdk vm-disk.qcow2

# Importar a Proxmox (directo a Ceph pool)
qm importdisk 100 vm-disk.qcow2 ceph-ssd --format raw

# Para VMs grandes, conversion directa a raw en Ceph (mas rapido)
qemu-img convert -f vmdk -O raw vm-disk.vmdk rbd:ceph-ssd/vm-100-disk-0

# Verificacion de integridad
qemu-img check vm-disk.qcow2
qemu-img compare vm-disk.vmdk vm-disk.qcow2

El piloto reveló dos problemas importantes que resolvimos antes de la migración masiva:

Fase 4: Migración masiva (semanas 4-8)

Con el piloto validado, entramos en modo migración. Cada sábado, en ventanas de mantenimiento de 4 horas (de 06:00 a 10:00), migrábamos lotes de 50 a 80 VMs. Automatizamos todo el proceso con scripts bash:

#!/bin/bash
# migrate_batch.sh - Migracion por lotes VMDK -> Proxmox/Ceph
BATCH_FILE="$1"          # CSV: vmname,vmid,pool,node
LOG="/var/log/migration/$(date +%Y%m%d).log"

while IFS=',' read -r vmname vmid pool node; do
    echo "[$(date)] Migrando $vmname -> VMID $vmid en $node" | tee -a "$LOG"

    # 1. Exportar VMDK via SSH desde ESXi
    ssh esxi "vim-cmd vmsvc/power.off \
      \$(vim-cmd vmsvc/getallvms | grep $vmname | awk '{print \$1}')"
    scp esxi:/vmfs/volumes/datastore1/$vmname/$vmname.vmdk /tmp/migration/

    # 2. Convertir e importar directamente al pool Ceph
    qemu-img convert -p -f vmdk -O raw \
      /tmp/migration/$vmname.vmdk rbd:$pool/vm-${vmid}-disk-0

    # 3. Crear config de VM en Proxmox
    qm create $vmid --name "$vmname" --memory 4096 --cores 2 \
      --net0 virtio,bridge=vmbr0 --ostype l26 \
      --scsi0 $pool:vm-${vmid}-disk-0 --scsihw virtio-scsi-single \
      --boot order=scsi0

    # 4. Verificacion
    qm start $vmid
    sleep 30
    qm agent $vmid ping && echo "[OK] $vmname operativa" | tee -a "$LOG"

    # 5. Cleanup
    rm /tmp/migration/$vmname.vmdk
done < "$BATCH_FILE"

Para las VMs críticas — servidores SQL Server, Exchange y el ERP — no podíamos permitirnos ninguna ventana de mantenimiento. Usamos una estrategia de replicación en caliente:

Fase 5: Optimización y decommission (semanas 8-10)

Con todas las VMs migradas, dedicamos dos semanas a optimizar el rendimiento del cluster Ceph y completar la transición:

# Tuning Ceph OSD para NVMe
ceph config set osd.* bluestore_cache_size_hdd 1073741824
ceph config set osd.* bluestore_cache_size_ssd 3221225472
ceph config set osd.* osd_memory_target 4294967296

# Balanceo de PGs
ceph balancer mode upmap
ceph balancer on

# Ajuste de recovery para no impactar produccion
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_recovery_sleep_hdd 0.1
ceph config set osd osd_max_backfills 1

# Verificacion de salud
ceph health detail
ceph osd pool stats

En paralelo, formamos al equipo IT del cliente con sesiones prácticas de 3 días cubriendo gestión de VMs, Ceph, backups, HA y resolución de problemas. Entregamos documentación completa de todo el entorno y un runbook para incidencias. Finalmente, hicimos el decommission de los hosts ESXi: formato, reclamación de licencias y retirada del vCenter.

Resultados: los números hablan

Lecciones aprendidas: 5 consejos para tu migración

Cronología completa

Te toca a ti

Si estáis ante una renovación de VMware con precios desorbitados, o simplemente queréis explorar alternativas abiertas con soporte profesional, podemos ayudaros. Llevamos años desplegando y gestionando entornos Proxmox con Ceph en producción para empresas de todo tamaño. Cada proyecto es diferente, pero la experiencia acumulada nos permite planificar migraciones con garantías.