Cómo validar el layout de Proxmox para un homelab AM5 y workstation AI local

Problema

Al montar un servidor bare‑metal con Proxmox VE, los administradores deben decidir cómo organizar discos, redes y dispositivos de hardware para soportar una mezcla de VMs: sistemas ligeros (Home Assistant, contenedores Docker), máquinas de uso intensivo (Windows 11, AI con GPU) y pruebas ocasionales. La dificultad radica en elegir una solución de almacenamiento que permita expansión futura, definir una arquitectura de red que aproveche NICs de 10 GbE y 5 GbE sin perder flexibilidad, y preparar el host para GPU passthrough sin comprometer la capacidad de snapshot de las VMs que no requieren acceso directo al hardware. Un diseño inadecuado puede obligar a reformatear discos, rehacer puentes de red o volver a instalar el hipervisor cuando se añada una GPU.

Causa

1. Almacenamiento monolítico – Usar un único NVMe con un sistema de archivos tradicional (ext4, XFS) impide la granularidad que exige Proxmox para snapshots y clones de VMs. Además, la falta de redundancia y de gestión de caché puede afectar el rendimiento de workloads AI.

2. Redes sin aislamiento – Conectar todas las VMs a la misma bridge física hace que el tráfico de gestión, almacenamiento y carga de trabajo AI compita por ancho de banda, y dificulta la asignación de VLANs o QoS cuando se añaden NICs adicionales.

3. Passthrough configurado a posteriori – Si el host no está preparado (IOMMU, ACS, VFIO‑PCI) antes de crear las VMs, la reconfiguración implica mover discos, cambiar IDs de dispositivos y, en el peor caso, reinstalar Proxmox.

4. Backups en un solo disco – Con una única unidad NVMe, cualquier fallo de hardware elimina tanto la VM como sus copias de seguridad, lo que rompe la estrategia de recuperación.

Solución

1. Almacenamiento: ZFS con datasets y volúmenes

• ZFS ofrece protección contra corrupción, snapshots rápidos y la posibilidad de crear datasets con cuotas y compresión por separado.

• Crea un pool llamado rpool usando el NVMe de 4 TB.

• Dentro del pool, define datasets para cada categoría de VM:

  • rpool/vmdata → volúmenes (zvol) para VMs que requieren discos de bloque (Windows, AI).
  • rpool/docker → dataset con compression=lz4 para contenedores y archivos de configuración.
  • rpool/homeassistant → dataset con quota=200G para aislar Home Assistant.

• Cuando añadas más NVMe, extiende el pool con zpool add y habilita L2ARC o ZIL en SSDs dedicados si el rendimiento de escritura se vuelve crítico.

2. Red: Bridges dedicados y VLANs

• Bridge vmbr0 → conecta la NIC de 10 GbE (eth0) y sirve para tráfico de gestión y almacenamiento (iSCSI, NFS).
• Bridge vmbr1 → conecta la NIC de 5 GbE (eth1) y se asigna a VMs de consumo intensivo (Windows, AI).
• Usa iptables o ebtables para aplicar QoS si la carga de AI compite con el tráfico de gestión.
• Configura VLANs en cada bridge si planeas exponer servicios a subredes distintas (ej. VLAN 10 para Home Assistant, VLAN 20 para AI).

3. GPU Passthrough preparado desde el inicio

1. BIOS: habilita SVM (AMD‑V), IOMMU, ACS Override (si la placa lo permite) y deja el iGPU activo para consola del host.
2. Proxmox: añade intel_iommu=on o amd_iommu=on al kernel en /etc/default/grub y ejecuta update-grub.
3. VFIO: crea /etc/modprobe.d/vfio.conf con:

   options vfio-pci ids=10de:1eb8,10de:10f0
   

   (reemplaza los IDs por los de tu GPU).
4. Blacklist: evita que el driver nouveau o amdgpu cargue la tarjeta antes de VFIO.
5. PCIe ACS: si la motherboard no expone ACS, usa el kernel parameter pcie_acs_override=downstream para forzar la separación de dispositivos.

Con esta base, la VM AI puede ser creada con hostpci0: 01:00.0,pcie=1,x-vga=1 sin tocar la configuración de otras VMs.

4. Estrategia de backup en un solo disco

• Snapshots locales: usa zfs snapshot rpool/vmdata@$(date +%F_%H%M) antes de actualizaciones críticas.
• Exportación a archivo: programa vzdump para generar backups comprimidos en /rpool/backup.
• Rotación: mantiene 3 copias diarias, 7 semanales y 4 mensuales usando prune de zfs.
• Copias fuera‑site: monta un contenedor LXC con rclone que sincronice el directorio de backups a un bucket S3 o a un NAS cuando añadas almacenamiento externo.

5. Configuración de VMs comunes

6. LXC vs VM para Docker

Aunque LXC es más ligero, ejecutar Docker dentro de una VM evita conflictos de cgroups y permite snapshots consistentes. En entornos con GPU passthrough, una VM también simplifica la gestión de drivers y versiones de CUDA.

Cuándo aplicar esta solución

• Escenarios típicos: homelabs con una mezcla de workloads ligeros y pesados, planes de expansión de GPU, y necesidad de snapshots frecuentes.
• Síntomas que indican la solución: falta de espacio para snapshots, cuellos de botella de red entre gestión y carga de trabajo, o errores de “device is busy” al intentar pasar una GPU después de crear la VM.
• Exclusiones: entornos donde la redundancia de disco es obligatoria desde el día uno (RAID‑1/5) o donde la latencia de red es crítica y se prefiere una solución de red definida por software (OVS, SR‑IOV) en lugar de bridges simples.

Código

# 1. Crear pool ZFS en el NVMe de 4 TB
zpool create -f rpool /dev/nvme0n1

# 2. Datasets
zfs create -o compression=lz4 rpool/docker
zfs create -o quota=200G rpool/homeassistant
zfs create -o refreservation=150G rpool/vmdata

# 3. ZVOL para una VM (ej. Windows)
zfs create -V 150G -b 4K -o volmode=dev rpool/vmdata/win11

# 4. Añadir bridge vmbr0 (10 GbE) y vmbr1 (5 GbE) en /etc/network/interfaces
cat <<EOF >> /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 192.168.10.1/24
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

auto vmbr1
iface vmbr1 inet static
    address 192.168.20.1/24
    bridge_ports eth1
    bridge_stp off
    bridge_fd 0
EOF
systemctl restart networking

# 5. Configurar VFIO para la GPU (reemplaza IDs)
echo "options vfio-pci ids=10de:1eb8,10de:10f0" > /etc/modprobe.d/vfio.conf
update-initramfs -u
reboot

Verificación

1. ZFS: zpool status muestra ONLINE y zfs list confirma los datasets y volúmenes.
2. Red: brctl show debe listar vmbr0 con eth0 y vmbr1 con eth1. Prueba ping entre VMs en distintas bridges.
3. Passthrough: dentro del host, lspci -nnk | grep -A2 -i NVIDIA debe mostrar vfio-pci como driver. Inicia la VM AI y verifica que nvidia-smi funciona.
4. Backup: ejecuta vzdump 101 --mode snapshot --compress lzo y comprueba que el archivo aparece en /rpool/backup.
5. Snapshots: crea zfs snapshot rpool/vmdata@test y verifica con zfs list -t snapshot.

Notas adicionales

• iGPU para host: mantener el iGPU activo permite acceso a la consola del host sin necesidad de teclado físico, útil cuando la GPU dedicada está dedicada a la VM AI.
• L2ARC: si el AI workload genera mucha lectura aleatoria, añade un SSD de 500 GB como cache L2ARC (zpool add rpool cache /dev/nvme1n1).
• QoS: tc qdisc en eth0 y eth1 ayuda a priorizar el