Problema

Muchos administradores de Proxmox terminan usando soluciones de almacenamiento externas como TrueNAS o FreeNAS para obtener ZFS, snapshots y exportaciones NFS/iSCSI. Ese enfoque introduce una capa adicional de gestión, plugins que rara vez se usan y una UI que no está alineada con la de Proxmox. El resultado es una experiencia fragmentada: los nodos de Proxmox deben conectarse a un host externo, los backups y snapshots se manejan fuera del flujo de trabajo habitual y la alta disponibilidad (HA) del storage depende de la sincronía entre dos sistemas diferentes. En entornos homelab o pequeñas infraestructuras de producción, esa complejidad se traduce en más puntos de falla y mayor carga operativa.

Causa

  1. Separación de planes de control – Proxmox gestiona VM/CT y redes, mientras que TrueNAS gestiona ZFS y servicios de exportación. Cada herramienta tiene su propio daemon, API y modelo de permisos.
  2. Plugins y servicios innecesarios – TrueNAS incluye una gran cantidad de plugins (Jails, Docker, etc.) que consumen recursos y pueden generar vulnerabilidades si no se actualizan.
  3. Desalineación de UI – Los usuarios deben alternar entre la UI de Proxmox y la de TrueNAS, lo que dificulta la visibilidad de snapshots o configuraciones de HA desde un único panel.
  4. Falta de integración nativa de snapshots – Los snapshots de ZFS creados en TrueNAS no aparecen automáticamente como puntos de restauración dentro de la UI de Proxmox, obligando a scripts externos o a procesos manuales.

Solución

Implementar un “storage interno” basado en ZFS directamente sobre los nodos de Proxmox elimina la capa externa y permite exponer los volúmenes mediante NFS o iSCSI usando los mismos daemons que ya corre el host. El flujo queda así:

  1. Crear un pool ZFS en cada nodo – Utilizar discos dedicados o partitions RAID‑Z.
  2. Configurar datasets con propiedades optimizadas para VM – compression=lz4, recordsize=16K para discos virtuales y recordsize=1M para backups.
  3. Exponer los datasets:
    • NFS para discos de VM/CT que requieren acceso de archivo.
    • iSCSI para discos de bloque que necesitan rendimiento máximo y pueden ser presentados a varios nodos en modo clustered.
  4. Integrar el storage en Proxmox mediante la CLI o la UI, asignándole un ID y habilitando HA.
  5. Aprovechar los snapshots de ZFS directamente desde Proxmox: la UI permite crear un snapshot del dataset y asociarlo a una VM como punto de restauración.
  6. Automatizar backups con vzdump apuntando al dataset ZFS; la deduplicación y compresión de ZFS reducen el espacio usado.

Paso a paso resumido

  • Pool ZFS: zpool create -f rpool mirror /dev/sdb /dev/sdc
  • Dataset para VM: zfs create -o compression=lz4 -o recordsize=16K rpool/vmdata
  • Exportar NFS: zfs set sharenfs=on rpool/vmdata
  • Crear target iSCSI (usando targetcli): crear un LUN que apunte a rpool/vmdata/lun0.
  • Agregar storage en Proxmox: pvesm add nfs proxzfs-nfs 10.0.0.1:/rpool/vmdata --content images,rootdir o pvesm add iscsi proxzfs-iscsi 10.0.0.1:3260/iqn.2026-06.com.example:storage --content images,rootdir.
  • Activar HA: marcar el storage como “shared” y habilitar HA en los recursos VM/CT.

Cuándo aplicar esta solución

  • Entornos homelab o pymes donde el número de nodos es ≤ 5 y el hardware de disco está bajo control.
  • Necesidad de HA de storage sin depender de un appliance externo.
  • Requerimiento de snapshots consistentes que se gestionen desde la UI de Proxmox.
  • Limitaciones de recursos: cuando los plugins de TrueNAS consumen CPU/RAM que podrían dedicarse a las VM.

No es la mejor opción si:

  • Se dispone de un cluster de TrueNAS con replicación ZFS entre sitios y se necesita una arquitectura de almacenamiento distribuido a gran escala.
  • Los nodos de Proxmox están en diferentes subredes sin conectividad de baja latencia para iSCSI.

Código

# 1. Crear pool ZFS con espejo
zpool create -f rpool mirror /dev/sdb /dev/sdc

# 2. Dataset para máquinas virtuales
zfs create -o compression=lz4 -o recordsize=16K rpool/vmdata

# 3. Habilitar export NFS (opcional)
zfs set sharenfs=on rpool/vmdata

# 4. Configurar iSCSI target (requiere targetcli)
targetcli /iscsi create iqn.2026-06.com.example:proxstorage
targetcli /iscsi/iqn.2026-06.com.example:proxstorage/tpg1/luns create /backstores/block/rpool/vmdata/lun0
targetcli /iscsi/iqn.2026-06.com.example:proxstorage/tpg1/acls create iqn.2026-06.com.example:proxmox

# 5. Añadir storage NFS a Proxmox
pvesm add nfs proxzfs-nfs 10.0.0.1:/rpool/vmdata --content images,rootdir

# 6. Añadir storage iSCSI a Proxmox
pvesm add iscsi proxzfs-iscsi 10.0.0.1:3260/iqn.2026-06.com.example:proxstorage --content images,rootdir

# 7. Marcar como shared y habilitar HA
pvecm addnode <node>
ha-manager add proxzfs-nfs --shared 1

Verificación

  1. zpool status – debe mostrar el pool rpool en estado ONLINE.
  2. zfs list -t filesystem – confirma que rpool/vmdata está creado con la compresión deseada.
  3. En Proxmox, abre la sección Datacenter → Storage y verifica que proxzfs-nfs y proxzfs-iscsi aparecen como “Enabled”.
  4. Crea una VM de prueba, asigna disco desde el nuevo storage y ejecuta vzdump <VMID> --mode snapshot. El dump debe completarse sin errores y el archivo debe residir en rpool/vmdata.
  5. Genera un snapshot ZFS manual: zfs snapshot rpool/vmdata@snap-test. Luego, desde la UI de Proxmox, selecciona “Rollback” y verifica que la VM vuelve al estado anterior.

Notas adicionales

  • Memoria RAM: ZFS recomienda al menos 1 GB de RAM por TB de capacidad. En nodos con menos de 8 GB, ajusta zfs_arc_max para evitar que el host agote memoria.
  • Red de iSCSI: usa VLAN dedicada o redes de 10 GbE para evitar cuellos de botella.
  • Backup externo: aunque el storage sea interno, sigue recomendable replicar snapshots a otro servidor mediante zfs send/receive.
  • Actualizaciones: mantén el kernel y los paquetes ZFS alineados con la versión de Proxmox; una desincronía puede causar errores de módulo.
  • Permisos: al exponer NFS, define sharenfs="[email protected]/24" para limitar el acceso a los nodos del cluster.

Con este enfoque, el storage se vuelve una extensión natural de Proxmox, se reduce la superficie de ataque y se gana consistencia en la gestión de snapshots y HA. La solución es lo suficientemente ligera para homelabs y escalable para pequeñas infraestructuras que buscan simplicidad sin sacrificar la potencia de ZFS.