Problema

Muchas organizaciones están dejando atrás licencias costosas de VMware y buscan una plataforma de virtualización basada en Linux que ofrezca mayor control y menores costos operativos. El reto típico consiste en mover decenas de máquinas virtuales (VM) en producción, conservar la capacidad de restauración rápida y, al mismo tiempo, sustituir la solución de backup propietaria (Veeam) por una alternativa integrada como Proxmox Backup Server (PBS). El proceso implica tres áreas críticas: estabilidad del repositorio de paquetes, compatibilidad de drivers en sistemas Windows y la integridad de los backups durante y después de la migración. Ignorar cualquiera de estos puntos suele traducirse en caídas inesperadas, pérdida de datos o una carga de trabajo de soporte que se dispara.

Causa

  1. Repositorios sin suscripción
    Proxmox ofrece un repositorio Enterprise que garantiza paquetes firmados y actualizaciones probadas. En clústers sin suscripción, el repositorio Community puede introducir versiones con bugs o dependencias rotas, lo que se vuelve crítico cuando el entorno pasa de pruebas a producción.

  2. Drivers y herramientas de virtualización
    Las VMs Windows creadas bajo ESXi llevan instalados VMware Tools y dependen de controladores SCSI/PCI específicos. Al arrancar directamente en Proxmox, el hipervisor intenta usar el controlador IDE por defecto, lo que provoca arranques fallidos o rendimiento degradado. La ausencia de los drivers VirtIO y la presencia residual de VMware Tools son la causa más frecuente de fallos post‑migración.

  3. Modelo de backup diferente
    Veeam maneja backups basados en snapshots de VMware y ofrece “application‑aware processing” que interactúa con VSS en Windows y con herramientas de quiescing en Linux. PBS, aunque excelente en deduplicación, no ejecuta VSS de forma automática; si la VM no está preparada, los backups pueden quedar inconsistentes.

  4. Almacenamiento compartido y HA
    En entornos con Ceph, ZFS o LVM‑thin, la migración de discos a formatos compatibles (qcow2, raw) sin planificar la replicación puede romper la alta disponibilidad. Además, PBS necesita un datastore propio o una integración ZFS para aprovechar la deduplicación; mezclarlo con el datastore de VM sin aislarlo genera cuellos de botella.

Solución

1. Decidir el repositorio adecuado

  • Entorno de producción: habilitar la suscripción Enterprise y apuntar /etc/apt/sources.list.d/pve-enterprise.list al repositorio oficial.
  • Entorno de pruebas: el repositorio Community está bien, pero bloquear actualizaciones automáticas con apt-mark hold en paquetes críticos (pve‑kernel, qemu‑guest‑agent) hasta validar en staging.

2. Preparar las VMs Windows

  1. Desinstalar VMware Tools desde el panel de control o con vmware-toolbox-cmd uninstall.
  2. Instalar drivers VirtIO antes de la exportación: montar el ISO virtio-win.iso dentro de la VM, copiar los drivers de viostor (SCSI) y vioscsi (paravirtual) al disco, y registrar el controlador con pnputil /add-driver.
  3. Cambiar el controlador de disco a VirtIO en el Administrador de dispositivos; marcar la opción “Eliminar el controlador anterior” para evitar conflictos.
  4. Crear una instantánea limpia después de la instalación y exportar la VM como OVF/OVA o directamente con vmkfstools -e.

3. Exportar e importar VMs

  • OVF/OVA: funciona para la mayoría de sistemas operativos, pero pierde la alineación de bloques en discos grandes.
  • QEMU‑img: usar qemu-img convert -O qcow2 source.vmdk dest.qcow2 para obtener un disco listo para Proxmox.
  • Importar: crear la VM en Proxmox con la configuración deseada (qm create), asignar el disco con qm importdisk <vmid> dest.qcow2 local-lvm y luego conectar el disco como virtio0.

4. Configurar PBS como backend de backup

  1. Instalar PBS en un nodo dedicado o en una VM con almacenamiento ZFS.
  2. Crear un datastore en Proxmox VE (Datacenter → Storage → Add → Proxmox Backup Server).
  3. Definir políticas de backup que incluyan prune-schedule y compression=fast.
  4. Habilitar VSS en Windows: instalar el paquete vssadmin dentro de la VM y crear un script que invoque vssadmin StartBackup antes de que PBS inicie el backup. En Proxmox, usar la opción “Enable VSS” en la tarea de backup.

5. Asegurar HA y rendimiento

  • Separar datastores: usar un pool ZFS exclusivo para PBS y otro para discos de VM.
  • Configurar replicación: si el clúster usa Ceph, crear un pool pbs con réplica 3 y montar como pbs en cada nodo.
  • Ajustar I/O Scheduler: para discos VirtIO, establecer scheduler=none y habilitar writeback en ZFS para reducir latencia.

Cuándo aplicar esta solución

  • Señales: planeas migrar >30 VMs, tienes licencias VMware que expiran pronto, y buscas una solución de backup con deduplicación nativa.
  • Entorno compatible: Proxmox VE 8.x o superior, nodos con CPU que soporten VT‑x/AMD‑V, y al menos un nodo con ZFS o Ceph.
  • No aplica: si tu infraestructura depende exclusivamente de funcionalidades Veeam que PBS no reproduce (por ejemplo, backup de bases de datos Oracle con plug‑in Veeam) o si no puedes adquirir una suscripción Enterprise y necesitas estabilidad garantizada.

Código

# Paso 1: desactivar repositorio Community y habilitar Enterprise
sed -i 's/^#deb/deb/' /etc/apt/sources.list.d/pve-enterprise.list
apt update && apt upgrade -y

# Paso 2: convertir VMDK a QCOW2
qemu-img convert -O qcow2 /path/to/source.vmdk /var/lib/vz/images/101/vm-101-disk-0.qcow2

# Paso 3: crear VM y asignar disco VirtIO
qm create 101 --name win10 --memory 8192 --net0 virtio,bridge=vmbr0
qm importdisk 101 /var/lib/vz/images/101/vm-101-disk-0.qcow2 local-lvm
qm set 101 --scsihw virtio-scsi-pci --virtio0 local-lvm:vm-101-disk-0
qm set 101 --boot c --bootdisk virtio0
qm start 101

Verificación

  1. Arranque de la VM: confirmar que Windows inicia sin errores de controlador y que el disco aparece como “VirtIO SCSI”.
  2. Integridad del backup: ejecutar una tarea de backup en PBS, luego restaurar la VM en un nodo de prueba y validar que los servicios (SQL, IIS) inician sin mensajes de VSS.
  3. Rendimiento de I/O: usar fio dentro de la VM y comparar contra métricas de ESXi; la latencia debe estar por debajo de 2 ms en operaciones de 4 KB.
  4. HA: simular la caída de un nodo (shutdown) y verificar que la VM se migra automáticamente al nodo restante sin pérdida de datos.

Notas adicionales

  • Snapshots en Proxmox: los snapshots de ZFS son instantáneos a nivel de bloque; no sustituyen a los backups de aplicación. Usa ambos: snapshots para pruebas rápidas y PBS para copias de seguridad a largo plazo.
  • Veeam‑to‑PBS migration: exporta los backups de Veeam como VHDX y conviértelos con qemu-img; luego importa a PBS con proxmox-backup-client restore. No hay una herramienta oficial de importación directa, así que planifica tiempo para la conversión.
  • Licencias de Windows: al mover una VM a otro hipervisor, Windows puede requerir re‑activación. Mantén los archivos de activación a mano y verifica la política de licenciamiento de tu organización.
  • Monitoreo: integra prometheus-node-exporter y pve-exporter para observar la salud de los nodos y del datastore PBS; alerta cuando el uso de deduplicación supere el 80 % del espacio asignado.
  • Documentación interna: guarda los scripts de conversión y los pasos de instalación de drivers en un repositorio Git; facilita la reproducibilidad cuando necesites añadir nuevas VMs al proceso.