Problema

Muchas organizaciones que han crecido sobre VMware con vSAN llegan a un punto donde la flexibilidad o el coste del stack propietario se vuelve limitante. La decisión de pasar a Proxmox implica replantearse el modelo de almacenamiento: el cluster original usaba vSAN como capa distribuida y Veeam para backups a nivel de storage. En la nueva infraestructura solo se dispone de un LUN iSCSI adicional y no se cuenta con un sistema de archivos distribuido como Ceph. El reto es elegir una solución de almacenamiento que:

  • soporte snapshots y clones de VM,
  • sea suficientemente robusta para producción,
  • permita almacenar ISOs, plantillas y backups sin crear cuellos de botella,
  • funcione con un número limitado de LUNs.

Causa

Los problemas habituales en este tipo de migración provienen de tres áreas:

  1. Modelo de bloques vs. modelo de archivos – vSAN expone discos virtuales directamente a los hipervisores. Cuando se pasa a Proxmox, el administrador debe decidir si usar un storage pool basado en bloques (iSCSI/LVM) o en archivos (NFS/ZFS). Cada modelo tiene limitaciones de snapshots y de rendimiento de I/O simultáneo.

  2. Número de LUNs insuficiente – Un único LUN iSCSI puede servir para VM disks, ISOs y backups, pero la contención de I/O y la complejidad de la gestión de permisos aumentan rápidamente. La práctica recomendada es separar datos críticos (VM disks) de datos auxiliares (templates, backups) en al menos dos LUNs.

  3. Falta de capa de deduplicación o compresión – Veeam aprovecha la capacidad de vSAN para deduplicar datos a nivel de bloque. Sin una capa similar, los backups pueden crecer desproporcionadamente y saturar el almacenamiento disponible.

Solución

1. Arquitectura recomendada

Función Tipo de storage Por qué
Discos de VM LVM sobre iSCSI (raw) Acceso directo, bajo overhead, snapshots nativas de Proxmox (via qm snapshot).
ISOs y plantillas ZFS sobre iSCSI (dataset) ZFS brinda compresión y snapshots de nivel de archivo, ideal para archivos estáticos.
Backups de Veeam → Proxmox ZFS dataset dedicado Compresión ZFS reduce tamaño, snapshots permiten retención sin impactar VM.

Esta separación mantiene la latencia mínima para los discos de VM mientras aprovecha las ventajas de ZFS para datos menos críticos.

2. Configuración paso a paso

a) Provisionar LUNs en el array SAN

  1. Crea al menos dos LUNs:

    • lun_vm (≈ 70 % del espacio total)
    • lun_aux (≈ 30 % del espacio total)

  2. Habilita CHAP y multipath (si el hardware lo permite) para resiliencia.

b) Conectar iSCSI al nodo Proxmox

iscsiadm -m discovery -t sendtargets -p <IP_SAN>
iscsiadm -m node --login
multipath -ll   # verifica que aparezcan los dm‑multipath devices

c) Crear LVM en lun_vm

pvcreate /dev/mapper/mpatha   # asume que multipath expone /dev/mapper/mpatha
vgcreate pve-vm /dev/mapper/mpatha
lvcreate -L 100G -n vmdata pve-vm   # ejemplo de LV para discos de VM

En la UI de Proxmox, añade un Directory storage apuntando a /dev/pve-vm/vmdata con tipo LVM.

d) Crear ZFS sobre lun_aux

zpool create -f pve-aux /dev/mapper/mpathb
zfs create -o compression=lz4 pve-aux/isos
zfs create -o compression=lz4 pve-aux/backups

En Proxmox, añade dos storages tipo ZFS que apunten a pve-aux/isos y pve-aux/backups.

e) Habilitar snapshots en Proxmox

Con LVM, Proxmox ya permite snapshots de discos (qm snapshot). Con ZFS, los snapshots se crean automáticamente al ejecutar qm snapshot y se almacenan como clones ZFS, lo que reduce el tiempo de creación y el consumo de espacio.

3. Migrar VMs y datos

  1. Exporta cada VM desde vCenter como OVF/OVA.
  2. Importa en Proxmox usando qm importovf. Apunta al storage LVM para los discos y a ZFS/isos para los archivos ISO.
  3. Verifica que los discos aparecen como raw en LVM; si están en qcow2, conviértelos con qemu-img convert -f qcow2 -O raw.

4. Integrar Veeam con Proxmox

Veeam no tiene un plugin nativo para Proxmox, pero puede trabajar a nivel de storage snapshots:

  • Configura Veeam para usar NAS backup repository apuntando a pve-aux/backups (NFS export de ZFS).
  • Habilita Veeam Backup Copy con compresión ZFS para reducir tráfico.
  • En caso de restaurar una VM, usa el backup NFS y crea una nueva VM apuntando al storage LVM.

5. Consideraciones de rendimiento

  • IOPS: LVM sobre iSCSI entrega latencia similar a vSAN siempre que el SAN tenga suficiente caché.
  • Compresión: ZFS lz4 tiene bajo overhead y mejora el rendimiento de lectura de ISOs y backups.
  • Snapshots: Los snapshots de LVM son copy‑on‑write; evita crear demasiados simultáneos en discos críticos. En ZFS, los snapshots son prácticamente sin coste de CPU.

Cuándo aplicar esta solución

  • Entorno de producción con 2‑3 nodos Proxmox y sin Ceph disponible.
  • Disponibilidad de al menos un SAN iSCSI que pueda ofrecer dos LUNs.
  • Requisitos de snapshots y clones para pruebas o despliegues rápidos.
  • Backups basados en Veeam que pueden redirigirse a un repositorio NAS.

No es adecuada si:

  • Solo se cuenta con un único LUN y no es posible crear más (la contención de I/O será crítica).
  • Se necesita replicación de bloques a nivel de sitio remoto; en ese caso Ceph o DRBD serían opciones más seguras.
  • El hardware SAN no soporta multipath o CHAP, lo que compromete la resiliencia.

Código

# Descubrimiento y login iSCSI
iscsiadm -m discovery -t sendtargets -p 10.0.0.10
iscsiadm -m node --login

# Multipath verification
multipath -ll

# LVM on first LUN
pvcreate /dev/mapper/mpatha
vgcreate pve-vm /dev/mapper/mpatha
lvcreate -l 100%FREE -n vmdata pve-vm

# ZFS on second LUN
zpool create -f pve-aux /dev/mapper/mpathb
zfs create -o compression=lz4 pve-aux/isos
zfs create -o compression=lz4 pve-aux/backups

Verificación

  1. Conectividad iSCSI: iscsiadm -m session debe listar ambas sesiones.
  2. Multipath: multipath -ll muestra dos dispositivos (mpatha, mpathb).
  3. LVM: lvs muestra el LV vmdata y su tamaño.
  4. ZFS: zfs list muestra los datasets pve-aux/isos y pve-aux/backups.
  5. Proxmox UI: Los storages aparecen bajo Datacenter → Storage con los tipos correctos.
  6. Snapshot test: Crea una VM, ejecuta qm snapshot 101 testsnap, verifica que el snapshot aparece en la lista y que el consumo de espacio no crece inmediatamente.
  7. Backup test: Ejecuta un job de Veeam apuntando a pve-aux/backups, confirma que el archivo .vbk se escribe y que la compresión ZFS reduce su tamaño al menos un 30 %.

Notas adicionales

  • Alineación de bloques: Cuando creas LVs, usa -Z para alinear al tamaño de bloque del SAN (normalmente 4 KB).
  • Redundancia: Si el SAN no ofrece RAID, considera habilitar ZFS mirroring en pve-aux (requiere al menos dos discos físicos).
  • Actualizaciones de firmware: iSCSI y multipath pueden romperse tras actualizaciones de firmware; mantén un plan de rollback.
  • Monitoreo: Integra smartctl y zpool status en tu stack de monitoring (Prometheus + node_exporter) para detectar degradaciones antes de que impacten en producción.
  • Plan de crecimiento: Reserva al menos 20 % de espacio libre en el pool LVM para evitar que los snapshots agoten el LUN.

Con esta arquitectura, la migración de un cluster VMware/vSAN a Proxmox se vuelve predecible, mantiene la capacidad de snapshots y ofrece un camino sólido para backups con Veeam sin necesidad de Ceph.