Mejor configuración Proxmox para homelab en 2026: hardware, NICs, diseño de almacenamiento y eficiencia energética

Objetivos de diseño para un homelab en 2026

Un “mejor” montaje es contextual. El truco es elegir restricciones que te mantengan fuera del barranco.

Objetivo 1: latencia predecible, no benchmarks pico

La mayoría de los homelabs no fallan porque sean lentos en sentido absoluto; fallan porque la latencia se vuelve impredecible. ZFS haciendo un resilver. Un NVMe barato que hace thermal-throttling. Una NIC i225 teniendo un mal día. Una VM en “SSD rápido” que en realidad está sobre un disco QLC sin área de reserva.

Objetivo 2: contención de fallos

Diseña de manera que la falla de un disco, un tropiezo de una PSU o un cambio de configuración erróneo no derribe todo. Aquí es donde arranque en espejo, pools separados y topología de red aburrida pagan el alquiler.

Objetivo 3: eficiencia energética que no comprometa la fiabilidad

Perseguir los vatios en reposo más bajos puede empujarte hacia plataformas tipo portátil con E/S frágil. Quieres “suficientemente eficiente” con controladores estables, ECC si es posible y un chasis que disipe sin gritar.

Objetivo 4: mantenibilidad bajo estrés leve

Si no puedes reemplazar un disco sin sacar toda la máquina del rack, no tienes un servidor. Tienes una caja de rompecabezas.

Una cita (idea parafraseada): Gene Kim repite a menudo la verdad operativa de que la fiabilidad viene de la retroalimentación rápida y los cambios pequeños, no de los héroes.

Broma #1: RAID no es una copia de seguridad; es solo que tus discos acordaron fallar en un calendario que no elegiste.

Datos interesantes e historia breve (por qué las cosas son así)

• Dato 1: ZFS se diseñó en Sun con sumas de verificación de extremo a extremo como característica central, precisamente para detectar la “corrupción silenciosa” que los RAID tradicionales te devuelven como datos válidos.
• Dato 2: Los primeros SSD de consumo hicieron el TRIM opcional; los sistemas de archivos modernos y el firmware de SSD asumen su existencia para mantener el rendimiento sostenido, especialmente en NAND QLC.
• Dato 3: 1GbE era “suficientemente rápido” hasta que la virtualización volvió el tráfico este-oeste algo normal. La migración de VMs, las copias de seguridad y la replicación de almacenamiento convirtieron a las redes en el nuevo bus de discos.
• Dato 4: iSCSI y NFS parecen sencillos hasta que aparece la latencia; la mayoría de los tickets “el almacenamiento es lento” son en realidad “la fluctuación de la red es mala” con mejor marca.
• Dato 5: El ARC de ZFS (caché en RAM) convirtió “más memoria” en una característica de rendimiento mucho antes de que fuera fashionable llamarlo “aceleración en memoria”.
• Dato 6: 2.5GbE de consumo despegó en gran parte porque los fabricantes de placas querían un diferenciador sin pagar PHYs 10GbE y el consumo asociado.
• Dato 7: NVMe no solo aumentó el ancho de banda; redujo la latencia de comandos al eliminar pilas de almacenamiento heredadas pensadas para discos giratorios.
• Dato 8: El auge de Proxmox sigue una tendencia mayor: la conveniencia operativa a menudo vence a la pureza teórica. “Un único panel” importa cuando estás cansado.

Elecciones de hardware que no arruinarán tu fin de semana

El punto óptimo 2026: un nodo potente o tres nodos más pequeños

En 2026, puedes permitirte ejecutar Proxmox en dos formas sensatas:

• Nodo “grande” único: lo más simple, barato, menos consumo y menos puntos de fallo. Inconveniente: el mantenimiento implica tiempo de inactividad a menos que lo diseñes para evitarlo.
• Clúster de tres nodos: mejor para experimentar HA, migración en caliente y actualizaciones por fases. Inconveniente: más consumo, más red y tarde o temprano depurarás quórum a la 1 a.m.

CPU: prioriza eficiencia, funciones de virtualización y carriles I/O

Quieres una CPU moderna con:

• Virtualización por hardware (AMD-V/Intel VT-x) e IOMMU (AMD-Vi/VT-d) para passthrough PCIe.
• Suficientes carriles PCIe para NVMe y una NIC sin compartir lanes que provoquen drama.
• Bajo consumo en reposo. Muchos homelabs pasan más tiempo en reposo que en pico.

Mi opinión: favorece una plataforma tipo servidor (o workstation prosumer) que soporte ECC y tenga actualizaciones de firmware estables. No porque ECC sea mágico, sino porque las placas que lo soportan suelen cuidar el entrenamiento de memoria y el ruteo de PCIe seriamente.

RAM: compra más de lo que crees y luego limita ARC intencionadamente

Para virtualización con respaldo ZFS, la RAM tiene tres tareas: memoria de invitados, caché ARC y metadatos. Para un nodo único que ejecuta un puñado de VMs y contenedores, 64 GB es el umbral “deja de preocuparte”. Para un nodo orientado a almacenamiento o un clúster de 3 nodos con replicación, 128 GB es cómodo.

No dejes que ARC se coma la máquina si ejecutas bases de datos que consumen memoria. Límitalo.

Placa base y plataforma: lo aburrido gana

Busca:

• IPMI o una función de gestión remota equivalente si puedes. No es solo para reiniciar; es para ver errores hardware cuando el SO está muerto.
• Dos ranuras PCIe utilizables (idealmente x8 eléctricas). Una para una NIC, otra para una HBA o NVMe extra.
• Suficientes ranuras M.2 con disipadores que en realidad toquen la unidad.
• Opciones BIOS para configurar ASPM y estados C sin romper dispositivos.

Chasis y refrigeración: quieres “silencioso bajo carga”, no “silencioso en reposo”

El flujo de aire es una característica de fiabilidad. Un chasis que permita ventiladores adecuados y direccione aire a los discos evitará que los SSD se estrangulen y que los HDD se cocinen. Además: los discos calientes mueren de forma aburrida, que es el peor tipo de muerte porque no lo notarás hasta que un scrub grite.

Fuente de alimentación: importan la eficiencia y el manejo de transitorios

Compra una PSU de calidad. No por “más vatios”, sino por potencia estable ante picos de carga. Las CPUs y GPUs modernas (incluso si no usas GPU) pueden causar cambios de carga bruscos. Una buena unidad 80 Plus Platinum suele ahorrar unos vatios en reposo y se comporta mejor cuando el UPS está resentido.

NICs, switching y sentido común con VLAN

Elige una NIC como eliges un sistema de archivos: por los drivers, no por la estética

En 2026, la red homelab por defecto es 2.5GbE. Es barata y suficiente para un nodo con almacenamiento local. Pero si haces cualquiera de estas cosas, ve a 10GbE:

• Proxmox Backup Server tirando grandes backups cada noche
• Replicación ZFS entre nodos
• Almacenamiento compartido (NFS/iSCSI) o Ceph
• Migración frecuente de VMs

10GbE: SFP+ sigue siendo la mejor opción

SFP+ tiene el ecosistema: cables DAC, bajo consumo y menos “PHY misteriosos” problemáticos. 10GbE RJ45 funciona, pero calienta más, suele consumir más en reposo y puedes construir accidentalmente un calentador de espacio que además corre Linux.

Topología recomendada

• Gestión: una VLAN (o puerto físico separado) para la UI de Proxmox, IPMI y switches.
• VM/Contenedor: una o varias VLAN según límites de confianza.
• Almacenamiento: si haces replicación o almacenamiento compartido, considera una VLAN y NIC dedicadas.

Configuración de bridge: mantenlo aburrido

El bridge de Linux con modo VLAN-aware funciona bien. Evita la creatividad como bridges anidados a menos que disfrutes depurar tormentas de broadcast creadas por tu propio optimismo.

Broma #2: La red más rápida del mundo no puede arreglar una VLAN etiquetada en el lugar equivocado. Los paquetes no leen tus intenciones.

Diseño SSD/HDD: pools ZFS, vdevs especiales y modos de fallo

Empieza por la carga de trabajo, no por el tipo de unidad

Tu homelab probablemente tenga tres patrones de almacenamiento:

• Arranque de VM y I/O aleatorio: sensible a la latencia, prefiere espejos NVMe.
• Medios / almacenamiento masivo: secuencial, barato por TB, adecuado en RAIDZ de HDD.
• Backups: ráfagas de escritura, retención intensa, quiere capacidad barata y tiempos de restauración predecibles.

Diseño base recomendado (nodo único)

• Arranque: 2 × SSD pequeños (SATA o NVMe) en espejo para el SO Proxmox. Manténlo separado. Trátalo como reemplazable.
• Pool de VM: espejo de 2 × NVMe (o espejo triple si odias las interrupciones menos de lo que amas el uptime). Aquí viven los discos de VM.
• Pool masivo: 4–8 × HDD en RAIDZ2 (o espejos si necesitas IOPS). Aquí va media, archivos y lo que no es sensible a latencia.
• Destino de backups: idealmente una caja separada (PBS) con su propio pool. Si tiene que ser local, usa un dataset separado con cuotas y retenciones sensatas.

Diseño base recomendado (clúster de tres nodos)

Dos caminos sensatos:

• ZFS local + replicación: cada nodo tiene espejo NVMe para VMs; replica VMs críticas a otro nodo; usa PBS para backups. Sencillo y eficiente.
• Ceph: solo si quieres aprender Ceph y puedes tolerar su sobrecarga. Es potente, pero pagas en RAM, red y tiempo.

recordsize, volblocksize en ZFS y por qué los valores por defecto no siempre son tu amigo

Para discos de VM almacenados como zvols, volblocksize importa. Para datasets, recordsize importa. No ajustes al azar. Ajústate cuando puedas describir el patrón de I/O en una frase.

• zvol general para VM: 16K es un valor razonable por defecto para muchas cargas.
• Bases de datos: a menudo se benefician de bloques más pequeños, pero prueba.
• Datasets de medios: recordsize 1M es común porque las lecturas son grandes y secuenciales.

SLOG y L2ARC: deja de comprar piezas antes de tener un problema

La mayoría de los homelabs no necesitan un SLOG. Si no haces writes sync sobre NFS/iSCSI a ZFS, un SLOG es un talismán caro.

L2ARC (caché secundaria en SSD) puede ayudar cargas de lectura que no caben en RAM, pero consume metadata en RAM. No es gratis. Si puedes comprar más RAM, haz eso primero.

vdevs especiales: útiles, pero afilados

Un vdev especial para metadatos y bloques pequeños puede hacer que un pool de HDD se sienta ágil. Pero si pierdes el vdev especial, pierdes el pool. Eso no es drama; es diseño. Si usas vdevs especiales, hazles espejo y monitoréalos como si fueran las joyas de la corona.

Selección de SSD: evita las mentiras de “barato y rápido”

Para pools de VM, prioriza el comportamiento de escritura sostenida y la resistencia. Una unidad que rinde bien 30 segundos y luego colapsa no es “rápida”; es “entusiasta momentánea”. Busca:

• Cache DRAM o al menos implementación HMB sólida
• Buen rendimiento de escritura sostenida (no solo picos SLC)
• Protección contra pérdida de energía si vas en serio (o al menos un UPS y ajustes conservadores)

Selección de HDD: planificar capacidad es planificar fallos

Para RAIDZ2, la capacidad es agradable hasta que los tiempos de resilver se alargan. Discos grandes significan largas ventanas de reconstrucción. Planifica una segunda falla durante el rebuild. Por eso existe RAIDZ2.

Eficiencia energética: adónde van realmente los vatios

El consumo en reposo es la factura que pagas cada hora

La mayoría de los homelabs están inactivos el 80–95% del tiempo. Dedica esfuerzo a reducir el consumo en reposo:

• Prefiere CPUs eficientes y placas con buen comportamiento en reposo.
• Deshabilita controladores no usados en BIOS (SATA extra, controladores RGB que no pediste, audio no usado).
• Usa menos ventiladores grandes a menor RPM en lugar de muchos pequeños chillando.
• Elige SFP+ sobre 10GBASE-T si te importa el consumo en reposo.

Los discos giratorios son honestos con su consumo

Los HDD consumen energía constante y generan calor. Si persigues bajo consumo, considera menos discos de mayor capacidad, pero recuerda la realidad de las ventanas de rebuild. Si persigues silencio, monta bien los discos y mantiene el flujo de aire suave.

Tamaño de la PSU: no exageres

Una PSU de 1200W funcionando a 60W en reposo puede ser menos eficiente que una unidad de 450–650W en su zona óptima. Compra calidad, dimensionada para tu pico realista más margen.

Tareas prácticas: comandos, salidas y decisiones

Estos son chequeos reales que puedes ejecutar en un host Proxmox. Cada uno incluye lo que significa la salida y la decisión que tomas a partir de ella. Hazlos en este orden cuando construyas, y otra vez cuando algo se sienta “raro”.

Task 1: Confirmar extensiones de virtualización e IOMMU

cr0x@server:~$ lscpu | egrep -i 'Model name|Virtualization|Flags'
Model name:                           AMD Ryzen 9 7900
Virtualization:                       AMD-V
Flags:                                ... svm ...

Significado: Quieres svm (AMD) o vmx (Intel). Si la virtualización aparece como “none”, es un ajuste de BIOS o un problema de plataforma.

Decisión: Si falta, habilita SVM/VT-x y IOMMU/VT-d en BIOS antes de construir cualquier otra cosa.

Task 2: Comprobar grupos IOMMU (preparación para passthrough)

cr0x@server:~$ find /sys/kernel/iommu_groups/ -type l | head
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:02.0

Significado: Los grupos existen; los dispositivos están aislados al menos algo. Si el directorio no existe, IOMMU no está habilitado.

Decisión: Si necesitas passthrough de GPU/NIC/HBA, valida la separación de grupos ahora, antes de comprar una placa que agrupe todo junto.

Task 3: Inventario de dispositivos de almacenamiento y velocidad de enlace

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN
NAME        MODEL                    SIZE ROTA TYPE TRAN
nvme0n1     Samsung SSD 990 PRO      1.8T    0 disk nvme
nvme1n1     Samsung SSD 990 PRO      1.8T    0 disk nvme
sda         ST12000VN0008-2YS101    10.9T    1 disk sata
sdb         ST12000VN0008-2YS101    10.9T    1 disk sata

Significado: ROTA 0 = SSD/NVMe, 1 = HDD. TRAN te dice el bus. Si tu “NVMe” aparece como SATA, algo anda mal.

Decisión: Confirma que realmente tienes los medios que planeaste. Esto detecta M.2 mal colocadas funcionando con menos lanes.

Task 4: Comprobar salud NVMe, temperatura y contadores de resistencia

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep 'temperature|percentage_used|data_units_written'
temperature                             : 41 C
percentage_used                         : 1%
data_units_written                      : 218,445

Significado: Temperatura bajo control, desgaste bajo. Temperaturas altas o desgaste que sube rápidamente significa que estás estrangulando o escribiendo demasiado (a menudo por swap, logs o suposiciones de caché erróneas).

Decisión: Si las temperaturas son altas, arregla el flujo de aire o añade disipadores. Si el desgaste sube rápido, mueve cargas de escritura intensiva o revisa los ajustes de ZFS y el logging.

Task 5: Verificar driver de NIC y estado del enlace

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp3s0           UP             3c:ec:ef:12:34:56
enp4s0           UP             3c:ec:ef:65:43:21

Significado: Interfaces UP. Ahora verifica velocidad/duplex.

Decisión: Si un puerto está DOWN y se supone que transporta tráfico de VM, para y arréglalo antes de culpar al almacenamiento.

Task 6: Comprobar velocidad negociada (detectar enlace 10G a 1G)

cr0x@server:~$ sudo ethtool enp4s0 | egrep 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Significado: Estás realmente a 10GbE. Si ves 1000Mb/s, tienes un problema de cableado/transceptor/configuración de switch.

Decisión: Arregla la capa física primero. No hay ajuste de software que haga bueno un cobre malo.

Task 7: Validar bridges con VLAN-aware en redes Proxmox

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto enp4s0
iface enp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.20/24
        gateway 192.168.10.1
        bridge-ports enp4s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Significado: Un bridge limpio con VLAN awareness activado. Si haces trunks, esta es la forma que quieres.

Decisión: Si ves bridges anidados o hacks post-up aleatorios, simplifica. La estabilidad vence a la ingeniosidad.

Task 8: Confirmar topología del pool ZFS (¿realmente estás en espejo?)

cr0x@server:~$ sudo zpool status
  pool: fast
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        fast          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1p3 ONLINE       0     0     0
            nvme1n1p3 ONLINE       0     0     0

errors: No known data errors

Significado: El espejo está sano. Si ves un vdev de disco único, estás a una falla de tener un mal día.

Decisión: Si la topología es incorrecta, arréglala antes de añadir datos. Migrar después es doloroso y suele implicar tiempo de inactividad.

Task 9: Comprobar ashift (¿alineaste para sectores 4K?)

cr0x@server:~$ sudo zdb -C fast | egrep 'ashift'
            ashift: 12

Significado: ashift=12 significa sectores de 4K, correcto para la mayoría de SSD y HDD modernos.

Decisión: Si construiste un pool con ashift=9, reconstruye el pool ahora. No es un knob de tuning posterior; es una elección vitalicia.

Task 10: Comprobar propiedades del dataset ZFS para almacenamiento de VMs

cr0x@server:~$ sudo zfs get -o name,property,value compression,atime,recordsize fast
NAME  PROPERTY     VALUE
fast  compression  zstd
fast  atime        off
fast  recordsize   128K

Significado: Compresión activada (bien), atime off (bueno para muchas cargas). Recordsize es relevante para datasets, no para zvols.

Decisión: Mantén la compresión a menos que tengas una razón específica. Si guardas imágenes de VM como archivos en un dataset, considera recordsize según I/O.

Task 11: Comprobar blocksize del zvol para un disco de VM

cr0x@server:~$ sudo zfs get -o name,property,value volblocksize fast/vm-101-disk-0
NAME                PROPERTY      VALUE
fast/vm-101-disk-0   volblocksize 16K

Significado: Razonable para discos de VM de propósito general.

Decisión: No cambies volblocksize después del hecho salvo que estés listo para recrear el zvol. Planifícalo temprano para cargas especiales.

Task 12: Monitorizar latencia I/O en tiempo real (encuentra el dolor de storage rápido)

cr0x@server:~$ sudo iostat -x 1 5
Device            r/s   w/s  r_await  w_await  aqu-sz  %util
nvme0n1         120.0  85.0     1.2     2.0    0.30   35.0
nvme1n1         118.0  83.0     1.1     1.9    0.28   33.0
sda               2.0  45.0    12.0    28.0    1.40   90.0

Significado: Latencia NVMe baja. Las escrituras en HDD muestran await más alto y alta utilización, lo que puede estar bien o ser tu cuello de botella.

Decisión: Si discos de VM están en HDD y ves w_await alto, muévelos a NVMe o rediseña el pool.

Task 13: Comprobar tamaño ARC y presión de memoria

cr0x@server:~$ arc_summary | egrep 'ARC Size|ARC Max Size|Memory Throttle'
ARC Size:                               28.3 GiB
ARC Max Size:                           48.0 GiB
Memory Throttle Count:                  0

Significado: ARC está activo pero no está limitando. Si el contador de throttle sube, tienes presión de memoria.

Decisión: Si la presión de memoria es real, añade RAM o limita ARC. No “optimices” dejando sin memoria a los invitados.

Task 14: Identificar principales consumidores de CPU y steal time (dolor de scheduling de VM)

cr0x@server:~$ top -b -n 1 | head -20
top - 11:22:19 up 12 days,  3:10,  1 user,  load average: 5.21, 4.88, 4.31
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.2 us,  4.1 sy,  0.0 ni, 77.1 id,  0.2 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem : 128000.0 total,   8200.0 free,  60200.0 used,  59600.0 buff/cache

Significado: wa alto sugiere espera I/O. st alto en un entorno virtualizado puede indicar contención en el host, pero en bare metal debería estar cerca de cero.

Decisión: Si wa es alto, revisa los chequeos de almacenamiento. Si la carga es alta pero la CPU está inactiva, sospecha I/O o contención de locks.

Task 15: Comprobar saneamiento de la configuración de almacenamiento en Proxmox

cr0x@server:~$ pvesm status
Name        Type     Status    Total     Used    Available
local       dir      active    98.0G     7.2G       90.8G
fast        zfspool  active     1.7T   420.0G        1.3T
bulk        zfspool  active    43.5T    12.1T       31.4T

Significado: Puedes ver dónde va el espacio. Si los discos de VM caen en local (root), estás a punto de llenar tu disco de arranque.

Decisión: Asegura que imágenes de VM y rootfs de contenedores vivan en el pool correcto, no en el disco del SO.

Task 16: Validar salud de backups (PBS o resultados de vzdump)

cr0x@server:~$ ls -lh /var/lib/vz/dump/ | tail -5
-rw-r----- 1 root root  22G Dec 28 02:10 vzdump-qemu-101-2025_12_28-02_00_01.vma.zst
-rw-r----- 1 root root 1.2G Dec 28 02:14 vzdump-lxc-103-2025_12_28-02_12_10.tar.zst

Significado: Los backups existen y son recientes. El tamaño parece plausible. Si esperabas 200 GB y obtuviste 2 GB, respaldaste lo equivocado (o la compresión ocultó tus pecados—raro).

Decisión: Prueba una restauración. El éxito de backup sin test de restauración es solo un registro optimista.

Guion de diagnóstico rápido (encuentra el cuello de botella)

Este es el orden que ahorra tiempo. El objetivo es dejar de adivinar y empezar a acotar.

Primero: decide si es contención de CPU, latencia de almacenamiento o red

• Sospecha CPU: alto uso de CPU en el host, síntomas de “ready time” en VMs, interfaz lenta bajo carga.
• Sospecha almacenamiento: alta espera I/O, arranques largos de VM, congelamientos durante backups, correlación con scrub/resilver de ZFS.
• Sospecha red: transferencias inconsistente, replicación lenta, picos de latencia, comportamiento “rápido a veces”.

Segundo: verifica la capa física y las tasas de enlace

Antes de tocar tunables de ZFS, confirma que tu NIC no esté negociando 1GbE, no esté perdiendo paquetes o esté en estado de enlace intermitente.

Tercero: aisla la carga

Encuentra qué VM/contenedor está causando el daño. En homelabs a menudo es:

• un cliente torrent mal configurado que traquetea metadata
• una vacuum/compaction de base de datos corriendo en HDD
• un trabajo de backup saturando el pool en hora punta
• una situación de memoria sobrecomprometida causando tormentas de swap

Cuarto: busca trabajo de mantenimiento ZFS

Los scrubs, resilvers y la eliminación masiva de snapshots pueden convertir un sistema sano en uno con tartamudeos. Eso es normal. La solución es planificación de horarios y capacidad, no culpas.

Quinto: revisa térmicas y throttling

El throttling térmico parece “lentitud aleatoria”. No es aleatorio. Es física.

Tres micro-historias corporativas de las que aprender

Incidente por una suposición errónea: “los espejos son rápidos, así que cualquier espejo sirve”

Una compañía mediana ejecutaba un clúster de virtualización con SSDs en espejo por host. Supusieron que “espejos SSD” significaba “suficientemente rápidos para todo”. Era verdad—hasta que dejó de serlo.

El problema empezó como pausas ocasionales de VM durante la ventana nocturna de backups. Nada dramático. Luego una VM de base de datos empezó a tener timeouts en horario laboral, y el equipo persiguió la configuración de la base porque eso es lo que hace la gente asustada y con cafeína.

El verdadero problema: el espejo estaba construido con unidades QLC de consumo con pequeñas caches SLC. Durante backups y churn de snapshots, las escrituras sostenidas superaron la cache y las unidades cayeron por un precipicio de rendimiento. La latencia se disparó. El hipervisor parecía culpable porque era el que estaba esperando.

Tenían monitorización, pero se centraba en throughput, no en percentiles de latencia. Así que los gráficos parecían “bien” mientras los usuarios sufrían. La solución fue aburrida: reemplazar las unidades por modelos con escrituras sostenidas estables y mover la preparación de backups fuera del pool principal de VM.

Lección: “Espejo SSD” no garantiza rendimiento. El comportamiento de escritura sostenida importa más que la etiqueta.

Optimización que salió mal: “Añadamos L2ARC para arreglar lecturas lentas”

Otro equipo tenía un pool ZFS grande y quería lecturas más rápidas para una carga con muchos ficheros. Añadieron un L2ARC SSD grande y celebraron porque los benchmarks mejoraron por una semana.

Luego el sistema empezó a comportarse de forma extraña: eventos de presión de memoria, reinicios ocasionales de servicios y caídas de rendimiento que parecían pausas de recolección. Culparon al kernel. Luego a la aplicación. Luego se culparon entre ellos, que es la ruta tradicional de escalado.

La causa fue sutil pero clásica: el overhead de metadata de L2ARC consumió RAM, reduciendo la efectividad del ARC y aumentando la presión del sistema. La carga no era lo bastante “read-hot” para justificar ese L2ARC de ese tamaño, y el churn del caché lo empeoró. Habían intercambiado caché RAM predecible por una caché SSD compleja que no coincidía con el patrón de acceso.

La solución fue eliminar el L2ARC sobredimensionado, añadir RAM y ajustar los patrones de acceso de la aplicación. Más tarde reintrodujeron un L2ARC más pequeño con límites estrictos tras medir los hit ratios reales.

Lección: Añadir caché puede reducir rendimiento si roba el recurso que realmente necesitabas (RAM) y no coincide con la carga.

Práctica aburrida pero correcta que salvó el día: “Probamos restauraciones mensuales”

Una tercera organización corría Proxmox con ZFS y un backup separado. Nada extravagante. Tenían un hábito que parecía casi tradicional: cada mes elegían una VM al azar y realizaban una restauración completa en una red aislada, luego verificaban funcionalidad a nivel de aplicación.

Un día, una actualización de firmware del controlador de almacenamiento introdujo resets intermitentes bajo I/O intenso. El primer signo no fue un host muerto; fueron discos de VM corruptos en un nodo después de un reset particularmente feo durante escrituras. ZFS hizo lo que pudo, pero un par de sistemas de archivos invitados no estaban limpios.

Porque habían ensayado restauraciones, la respuesta fue serena. Pusieron el nodo en cuarentena, restauraron las VMs afectadas desde backups conocidos buenos y mantuvieron el negocio funcionando mientras el proveedor de hardware resolvía lo que su firmware había hecho.

Sin heroísmos. Nada de “quizá esté bien”. Solo recuperación practicada.

Lección: Probar restauraciones es interés compuesto operativo. Es aburrido hasta que es lo único que importa.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: arranques de VM lentos, pero los benchmarks de throughput parecen bien

Causa raíz: picos de latencia por agotamiento de cache SSD, pool casi lleno o actividad de mantenimiento ZFS (scrub/resilver/eliminación de snapshots).

Solución: mantén pools ZFS por debajo de utilización incómoda (no vivas al 90%), programa scrubs, mueve trabajos de escritura intensa fuera del pool de VM y usa SSDs con escrituras sostenidas estables.

2) Síntoma: copias por red se estancan en ~110 MB/s en un setup “10GbE”

Causa raíz: enlace negociado a 1GbE, transceptor/cable defectuoso o puerto del switch configurado incorrectamente.

Solución: verifica con ethtool, cambia DAC/transceptor, confirma la configuración del switch. No ajustes buffers TCP para arreglar un problema físico.

3) Síntoma: host Proxmox se congela aleatoriamente bajo carga

Causa raíz: presión de memoria y tormentas de swap, throttling térmico de NVMe o suministro eléctrico inestable.

Solución: revisa dmesg por OOM y errores NVMe, añade RAM, limita ARC, mejora la refrigeración y usa una PSU + UPS de calidad.

4) Síntoma: scrub ZFS tarda una eternidad y el sistema se siente lento

Causa raíz: pool con muchos HDD y alta utilización, o contención de resilver/scrub con cargas activas.

Solución: ejecuta scrubs fuera de horas, considera espejos para uso IOPS-intenso y mantén capacidad libre. Si no puedes scrubear cómodamente, estás sobrecargado.

5) Síntoma: backups “exitosos” pero restauraciones fallan o están incompletas

Causa raíz: respaldar el almacenamiento equivocado, excluir volúmenes montados o corrupción silenciosa no detectada porque no se probaron restauraciones.

Solución: prueba restauraciones rutinariamente, verifica que el backup incluya los discos correctos y almacena backups en hardware separado cuando sea posible.

6) Síntoma: clúster Ceph funciona hasta que un nodo se reinicia y luego todo va lento

Causa raíz: red infra-provisionada, OSDs en discos de calidad mixta o RAM/CPU insuficientes para la sobrecarga de Ceph.

Solución: no ejecutes Ceph en hardware “de repuesto”. Si quieres HA, hazlo bien: red rápida, discos consistentes y suficiente memoria.

7) Síntoma: passthrough PCIe es inestable o los dispositivos desaparecen tras reinicio

Causa raíz: mala agrupación IOMMU, quirks de BIOS, compartir lanes o problemas de gestión de energía.

Solución: verifica grupos IOMMU, actualiza BIOS, evita risers y desactiva ASPM problemáticos para los dispositivos afectados.

Listas de verificación / plan paso a paso

Plan paso a paso: nodo único “homelab serio”

1. Elige la plataforma: placa estable, ECC si es posible, al menos dos ranuras PCIe y dos ranuras M.2.
2. Elige memoria: 64 GB mínimo, 128 GB si ejecutas muchas VMs, ZFS intenso o quieres margen.
3. Red: NIC SFP+ 10GbE si replicar o ejecutar un servidor de backups; de lo contrario 2.5GbE puede ser aceptable.
4. Espejo de arranque: dos SSD pequeños en espejo; mantiene el SO separado del pool de VM.
5. Pool de VM: espejo NVMe, prioriza resistencia y escrituras sostenidas.
6. Pool masivo: RAIDZ2 para capacidad; espejos si necesitas IOPS más que TB.
7. Backups: caja PBS separada si valoras tus datos. Si no, al menos datasets separados y cuotas.
8. Monitorización: sigue latencia (disk await), SMART/desgaste NVMe, salud de pool ZFS y velocidad de enlace. El throughput por sí solo es mentiroso.
9. Ensayo de restauración: restauración mensual de una VM aleatoria en una VLAN aislada.

Plan paso a paso: clúster de tres nodos para aprender HA

1. Estandariza nodos: mismas NICs, mismos modelos de disco cuando sea posible, mismas configuraciones BIOS.
2. Red primero: switching 10GbE, plan VLAN limpio, VLAN dedicada para almacenamiento/replicación si es posible.
3. Decide modelo de almacenamiento: ZFS local + replicación (recomendado) o Ceph (solo si vas a operar Ceph).
4. Conciencia de quórum: planifica qué pasa cuando un nodo cae. Añade un qdevice si hace falta para casos de dos nodos en el borde, pero lo ideal es tres nodos reales.
5. Backups siguen siendo separados: la replicación no es backup. PBS sigue importando.
6. Disciplina de actualizaciones: actualizaciones por fases, un nodo a la vez, con plan de rollback.

Lista de verificación en tiempo de construcción: no lo saltes

• BIOS actualizado a una versión estable (no necesariamente la más nueva).
• Virtualización + IOMMU habilitados.
• Prueba de memoria sobre la noche si puedes tolerar el tiempo.
• Temperaturas NVMe comprobadas bajo carga; sin throttling.
• Velocidad de enlace verificada en host y switch.
• Topología del pool ZFS verificada antes de que caiga datos.
• Horario de scrubs establecido y primer scrub observado.
• Backups configurados y una restauración de prueba completada.

Preguntas frecuentes (FAQ)

1) ¿Debo ejecutar Proxmox sobre ZFS o ext4/LVM?

Si te importan snapshots, integridad y operaciones predecibles, usa ZFS. Si necesitas la configuración más simple posible y aceptas menos barreras de seguridad, ext4/LVM está bien. Para la mayoría de homelabs serios: ZFS.

2) ¿Espejo o RAIDZ para almacenamiento de VMs?

Espejos para almacenamiento de VM a menos que tu carga sea mayoritariamente secuencial y tolerante a latencia. Los espejos dan mejores IOPS y un comportamiento de rebuild más simple. RAIDZ es genial para capacidad masiva y medios.

3) ¿Necesito memoria ECC?

No es obligatorio, pero es buena idea cuando ejecutas ZFS y te importa la integridad. Más importante, las plataformas con soporte ECC suelen estar construidas con menos carácter juguetón. Si la diferencia de precio es pequeña, compra ECC.

4) ¿2.5GbE es suficiente en 2026?

Para un nodo con almacenamiento local, sí. Para replicación, almacenamiento compartido o backups frecuentes, lo notarás. 10GbE (SFP+) es el salto limpio.

5) ¿Necesito un dispositivo SLOG para ZFS?

Solo si sirves escrituras sync (común en NFS/iSCSI con sync habilitado) y has medido que el camino ZIL es el cuello de botella. Si no, no compres un SLOG para sentirte productivo.

6) ¿Puedo ejecutar Ceph en tres nodos pequeños?

Puedes, y aprenderás mucho—principalmente por qué Ceph de producción quiere redes rápidas, mucha RAM y discos consistentes. Para “quiero que mis servicios sean aburridos”, ZFS local + replicación suele ser mejor.

7) ¿Cuál es la mejor configuración de disco de arranque?

Dos SSD pequeños en espejo. Mantén el SO fuera del drama de tu almacenamiento principal. Si el espejo de arranque falla, debe ser una molestia, no un evento existencial.

8) ¿Qué tan lleno puedo dejar un pool ZFS?

No lo trates como una maleta que cierras a la fuerza. A medida que los pools se llenan, la fragmentación y el dolor de rendimiento aumentan. Mantén espacio libre significativo, especialmente en pools de VM.

9) ¿Debería usar vdevs especiales en mi pool de HDD?

Sólo si entiendes el dominio de fallos: pierdes el vdev especial y pierdes el pool. Si lo haces, mirroréalos y monitoréalos agresivamente.

10) ¿Cuál es el enfoque de backup más simple y fiable?

Proxmox Backup Server en hardware separado, backups nocturnos con retención sensata y una copia periódica fuera de sitio. Luego prueba restauraciones. La última parte es el objetivo real.

Conclusión: próximos pasos prácticos

Construye para latencia predecible, recuperación aburrida y consumo con el que puedas convivir. El homelab ganador de 2026 no es el que tiene más cores; es el que menos te sorprende.

1. Decide tu arquitectura: un nodo sólido o tres nodos con replicación.
2. Compra la NIC y el switch pensando en estabilidad de drivers y verificación de velocidad de enlace.
3. Diseña el almacenamiento como preocupaciones separadas: espejo de arranque, pool rápido para VMs, pool masivo y backups fuera del host si puedes.
4. Ejecuta las tareas de comando arriba el primer día. Guarda las salidas. Se convierten en tu línea base.
5. Programa scrubs, backups y una prueba de restauración. Ponlo en el calendario como si fuera el alquiler.