Proxmox vs ESXi para ZFS: elegir la ruta del controlador de disco (HBA passthrough vs discos virtuales)

La decisión real: qué necesita ZFS vs qué ofrecen los hipervisores

ZFS no es tímido. Quiere acceso relativamente directo a los discos, identidades estables, semánticas de flush correctas, latencia predecible y visibilidad de errores.
Los hipervisores, por diseño, abstraen el hardware. A veces de forma hermosa. A veces de forma catastrófica.

Tu elección de controlador en realidad son tres elecciones agrupadas:

• Visibilidad: ¿Puede ZFS ver SMART, contadores de errores y el comportamiento real del dispositivo—o solo un dispositivo de bloque virtual?
• Orden y garantías de flush: Cuando ZFS dice “sync esto”, ¿la pila realmente lo sincroniza a un medio no volátil?
• Radio de explosión por fallo: ¿La “caché útil” de una capa convierte un fallo del host en corrupción del pool?

Si recuerdas una línea, que sea esta: ZFS puede tolerar discos lentos; no puede tolerar mentiras.
“Mentiras” aquí significa reconocimientos de escritura que no son todavía durables, o reportes de error que se tragan, reescriben o retrasan hasta que es demasiado tarde.

Entonces… ¿Proxmox vs ESXi?

Si quieres ZFS como tu pila de almacenamiento principal en el host: Proxmox es la opción directa porque es Linux, y ZFS-on-Linux es ciudadano normal allí.
Si quieres ESXi por su ecosistema de virtualización pero aún quieres las funciones de ZFS: usualmente hablas de ZFS dentro de una VM (TrueNAS, OmniOS, Debian+ZFS, etc.).
Eso es viable, pero la ruta del controlador se convierte en todo el juego.

Orientación con opinión:

• Mejor práctica para ZFS-en-VM: passthrough PCIe de una HBA en modo IT a la VM ZFS.
• Aceptable para carga ligera / laboratorio: discos virtuales (VMDK/virtio-blk) solo si entiendes lo que pierdes.
• Lo que evito en producción: poner ZFS encima de un controlador RAID que presenta volúmenes lógicos, o apilar ZFS sobre discos virtuales thin-provisioned sin protecciones.

Hechos interesantes y contexto histórico (que aún duele hoy)

1. ZFS nació en Sun Microsystems y se lanzó en Solaris (mediados de 2000), construido alrededor de checksums end-to-end y copy-on-write para evitar corrupción silenciosa.
2. Copy-on-write es la razón por la que ZFS odia las “cachés que mienten”: depende de grupos de transacciones y durabilidad ordenada; reconocimientos que no son durables pueden envenenar la consistencia tras un fallo.
3. Los datastores VMFS de VMware fueron diseñados para virtualización de bloque compartido, no para exponer semánticas de disco crudo a un sistema de archivos invitado con su propia lógica RAID.
4. Las HBA en “modo IT” se hicieron populares porque ZFS (y más tarde Ceph) quería comportamiento JBOD simple: sin metadatos RAID, sin sorpresas de caché del controlador.
5. Las tarjetas LSI SAS2008/SAS2308 (y sus muchas re-marcas OEM) se convirtieron en el estándar de homelab y PYMEs porque eran baratas y soportaban bien el passthrough.
6. Los discos con sectores 4K forzaron la mano de la industria: desajustes de ashift pueden desperdiciar IOPS y espacio; las capas de virtualización a veces ocultan el tamaño real del sector.
7. Las políticas de caché de escritura han causado incidentes reales durante décadas—mucho antes de ZFS—porque “caché activada” más “sin batería/protección” es simplemente “pérdida de datos después”.
8. El passthrough de SMART no es algo garantizado: muchos caminos de disco virtual no entregan detalles de salud al guest, lo que rompe flujos operativos proactivos.

Rutas de presentación de disco: HBA en passthrough, RDM, VMDK, y “depende”

Ruta A: Passthrough PCIe de la HBA (modo IT) a la VM ZFS

Este es el enfoque “deja de ser creativo”. La VM ZFS posee la HBA, enumera los discos directamente, ve SMART, ve seriales y obtiene el comportamiento real de errores.
Es lo más cercano al metal desnudo mientras virtualizas la computación alrededor.

Pros

• Mejor visibilidad de discos: SMART, temperaturas, contadores de errores, IDs reales de dispositivo.
• Mejor alineación con las asunciones de ZFS sobre flushes y manejo de errores.
• Características de rendimiento previsibles: el queueing y la latencia son menos “misteriosos”.
• Respuesta a incidentes más sencilla: cuando un disco está muriendo, ZFS te dice cuál, no “naa.600…algo”.

Contras

• Pierdes algunas comodidades del hipervisor (vMotion para esa VM, snapshots en el sentido habitual).
• El passthrough puede complicar actualizaciones del host y cambios de hardware.
• Algunas placas domésticas/agrupaciones IOMMU lo hacen fastidioso.

Ruta B: ESXi RDM (Raw Device Mapping) a una VM ZFS

RDM es el “más o menos crudo” de VMware. En la práctica sigue estando mediado.
Dependiendo del modo (virtual vs compatibilidad física), puede o no reenviar lo que ZFS necesita.
Puede ser viable, pero rara vez es la mejor opción cuando el passthrough está disponible.

Pros

• Mejor que un VMDK genérico para algunos casos de uso.
• Puede permitir cierta integración de herramientas con ESXi.

Contras

• La visibilidad SMART y de errores suele ser limitada o inconsistente.
• MÁS capas donde las semánticas de caché/flush pueden volverse extrañas.
• Ambigüedad operativa: “¿El guest realmente ve el disco?” se vuelve una pregunta recurrente.

Ruta C: Discos virtuales (VMDK en VMFS; virtio en Proxmox)

Esta es la forma más común en que la gente prueba ZFS en una VM porque es conveniente y se ve limpio en la UI.
También es donde ZFS recibe menos verdad sobre el medio subyacente.

Si haces esto para algo que te importa, trátalo como una decisión de producto: define requisitos de fiabilidad, prueba el comportamiento ante crashes y acepta los puntos ciegos de monitorización.

Pros

• Operaciones de ciclo de vida fáciles: migrar, snapshot, clonar.
• Independiente del hardware: no se necesita una HBA especial.
• Ideal para dev/test, CI, entornos desechables.

Contras

• ZFS pierde SMART directo y algunas semánticas de error.
• Tamaños de sector desalineados y cachés volátiles pueden crear problemas de rendimiento e integridad.
• Doble cacheo y queueing (guest + host) pueden producir picos de latencia que parecen “aleatorios”.

Broma #1: Discos virtuales para ZFS en producción son como poner neumáticos de carreras en una carretilla—técnicamente rueda, pero no obtendrás la velocidad que querías.

Ruta D: Controlador RAID hardware presentando volúmenes lógicos a ZFS

No lo hagas. ZFS ya es la capa RAID. Ponerlo encima de otra capa RAID es una gran forma de obtener:
manejo de fallos desajustado, errores enmascarados, comportamiento de write hole y un juego de culpas en soporte.

Hay excepciones nicho (RAID0 por disco en el controlador puramente para comportarse como passthrough),
pero normalmente es un parche cuando compraste el controlador equivocado.
Para builds nuevos: compra el hardware correcto.

Proxmox: ZFS es de primera clase, pero el hardware sigue importando

En Proxmox, ZFS normalmente se ejecuta en el host. Esa es la arquitectura más limpia: el kernel ve los discos directamente,
ZFS los gestiona directamente, y tus VMs ven almacenamiento mediante zvols, datasets o shares de red.

La “decisión del controlador” sigue existiendo, pero es más simple: o adjuntas discos al host Proxmox mediante una HBA adecuada (o SATA onboard en AHCI),
o te complicas la vida con controladores RAID y políticas de caché.

Qué comprar (y cómo configurarlo)

• HBA en modo IT (familia LSI/Broadcom) es la respuesta clásica para backplanes SAS/SATA y expanders.
• SATA onboard en modo AHCI está bien para builds pequeños con SATA directo, asumiendo que el chipset y el cableado sean sensatos.
• Evita el modo RAID a menos que puedas forzar verdadero comportamiento HBA/JBOD con caché deshabilitada e identificadores estables—sigue siendo la segunda mejor opción.

Chequeo de realidad de rendimiento

Proxmox con ZFS no es “lento.” Es honesto. Si tu pool son seis discos mecánicos haciendo escrituras sync, la latencia reflejará la física.
ZFS te mostrará la factura por tus decisiones de diseño.

ESXi: excelente hipervisor, historia incómoda para ZFS en guest

ESXi es excelente en lo que fue construido para hacer: ejecutar VMs, gestionarlas a escala, abstraer hardware y ofrecer herramientas operativas estables.
La fricción aparece cuando quieres que un sistema de archivos invitado (ZFS) se comporte como si estuviera en metal desnudo mientras ESXi hace lo que hacen los hipervisores.

Qué hacer en ESXi si quieres funciones de ZFS

• Mejor: dedica una HBA y usa passthrough PCIe a una VM de almacenamiento (TrueNAS, etc.). Presenta almacenamiento de vuelta a ESXi vía NFS/iSCSI.
• Regular: RDM en modo físico para cada disco, si el passthrough es imposible. Valida visibilidad SMART y comportamiento de flush.
• Arriesgado: ZFS sobre VMDKs en VMFS, especialmente thin-provisioned, con snapshots y sin monitoreo de la presión del datastore subyacente.

El problema filosófico: ¿quién es responsable de la integridad?

En un mundo ESXi + VMFS, la pila de VMware es responsable de la integridad del datastore, redundancia y recuperación.
En un mundo ZFS, ZFS quiere hacerse cargo de ese trabajo de extremo a extremo.
Si dejas que ambas pilas “ayuden”, puedes acabar sin que ninguna sea totalmente responsable.

Una cita que vale la pena pegar en una nota:
La esperanza no es una estrategia. — James Cameron

Por qué la elección del controlador cambia los modos de fallo (y tu pager)

1) ZFS necesita identidad de disco estable

ZFS etiqueta discos y espera que permanezcan como el mismo dispositivo.
Los discos virtuales son estables a su manera, pero ocultan la topología real del disco.
Si un disco físico comienza a dar errores, ZFS en el guest podría ver solo “error de lectura de disco virtual”, no “Seagate SN1234 está muriendo en bahía 7.”

2) SMART y señales predictivas de fallo

SMART no es perfecto, pero es lo que tenemos. Sectores realocados, pendientes, errores CRC—son advertencias tempranas.
Con passthrough puedes monitorizarlos dentro del sistema ZFS y reemplazar discos antes de que un resilver se convierta en un drama de una semana.
Con VMDKs, a menudo estás a ciegas a menos que también monitorices desde el host con herramientas separadas y corrobores manualmente.

3) Semánticas de flush de caché y escrituras sync

A ZFS le importa profundamente qué significa “sync”. A las bases de datos también.
Si el hipervisor o el controlador reconoce escrituras antes de que sean durables, una pérdida de energía puede dejar a ZFS creyendo que los datos están seguros cuando no lo están.
ZFS es robusto, pero no puede checksummar datos que nunca llegaron al disco.

4) Profundidad de cola y variación de latencia

Muchos reportes de “ZFS es lento en una VM” son en realidad “tu camino IO tiene tres colas, dos cachés y un cuello de botella pequeño.”
Las HBA en passthrough permiten que el guest gestione el queueing directamente.
Con discos virtuales, puedes obtener picos de latencia impredecibles por contención del host, operaciones de metadatos del datastore o cadenas de snapshots.

5) Recuperabilidad cuando el host está enfermo

Con HBA en passthrough, la VM ZFS es más autocontenida: mueve la HBA + discos a otro host, importa el pool y sigues.
Con VMDKs, tu pool queda enredado con datastores VMFS, configuración del host ESXi y a veces el estado de snapshots.
La recuperación se convierte en una excavación arqueológica de múltiples capas.

Broma #2: Las capas de almacenamiento son como la lasaña—si son demasiadas pasarás la noche lamentando tus elecciones.

Tareas prácticas: comandos, interpretación de salida, decisiones

El objetivo de los comandos no es sentirse ocupado. Es reducir la incertidumbre hasta que la decisión correcta sea obvia.
Abajo están tareas reales que uso en triage de producción y revisiones de diseño. Cada una incluye qué buscar y qué decidir después.

Tarea 1: Confirmar que ZFS ve discos reales (no un blob virtual gigante)

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TYPE
NAME   MODEL            SERIAL        SIZE ROTA TYPE
sda    ST12000NM0008    ZHZ1ABC1      10.9T    1 disk
sdb    ST12000NM0008    ZHZ1ABC2      10.9T    1 disk
sdc    ST12000NM0008    ZHZ1ABC3      10.9T    1 disk
nvme0n1 Samsung SSD 980 S64DNF0R1234   931G    0 disk

Qué significa: Tienes modelo y serial por disco. Eso normalmente indica conexión directa o HBA en passthrough.
Si ves “VMware Virtual disk” (o modelos/seriales idénticos), estás con discos virtuales.

Decisión: Si esto es una VM ZFS y te importa la visibilidad operativa, avanza hacia HBA passthrough.

Tarea 2: Verificar si el controlador es una HBA real y está en modo sensato

cr0x@server:~$ lspci -nn | egrep -i 'sas|sata|raid|lsi|broadcom'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0087]

Qué significa: Un dispositivo LSI SAS2308 es una HBA común adecuada para modo IT.
Si ves un modelo de controlador RAID, verifica que no esté haciendo caché de escritura o presentación RAID.

Decisión: Prefiere una HBA en modo IT para ZFS; evita volúmenes RAID hardware como vdevs de ZFS.

Tarea 3: Verificar passthrough desde la perspectiva del guest (VM ZFS)

cr0x@server:~$ dmesg | egrep -i 'mpt2sas|mpt3sas|scsi host' | tail -n 8
[    2.114012] mpt2sas_cm0: LSISAS2308: FWVersion(20.00.07.00), ChipRevision(0x05), BiosVersion(07.39.02.00)
[    2.116842] scsi host0: ioc0
[    2.116904] scsi host1: ioc1

Qué significa: El guest cargó el driver de la HBA y ve el controlador directamente.

Decisión: Procede con vdevs por disco; habilita monitorización SMART en el guest.

Tarea 4: Confirmar topología del pool ZFS (y detectar puntos únicos de fallo accidentales)

cr0x@server:~$ zpool status -v
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0

errors: No known data errors

Qué significa: RAIDZ2 sobre seis discos, sin errores. Si ves IDs scsi- que cambian seguido, puedes tener nombres de dispositivo inestables.

Decisión: Si los nombres de dispositivo son inestables, usa rutas /dev/disk/by-id al crear/reemplazar discos.

Tarea 5: Verificar ashift (alineación 4K) para evitar tristeza permanente de rendimiento

cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_tree' -n | head
41:        vdev_tree:
57:                ashift: 12

Qué significa: ashift: 12 implica sectores 4K. Si es 9 (512B) en discos 4K, puedes tener amplificación de escritura y menos IOPS.

Decisión: Si ashift está mal, reconstruye el pool. No hay botón mágico “arreglar ashift”.

Tarea 6: Medir la penalización por escrituras sync (te dice si SLOG importa)

cr0x@server:~$ zfs get -o name,property,value -s local,default sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

cr0x@server:~$ dd if=/dev/zero of=/tank/testfile bs=1M count=1024 oflag=dsync status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6 s, 43.6 MB/s

Qué significa: oflag=dsync aproxima el comportamiento de escrituras sync. 43 MB/s en discos giratorios podría ser normal; 3 MB/s sugiere un problema de flush/cola.

Decisión: Si las escrituras sync son un cuello de botella y tienes cargas reales sync (bases de datos, NFS con sync), añade un SLOG apropiado con protección contra pérdida de energía.

Tarea 7: Verificar la presencia de SLOG y qué está haciendo

cr0x@server:~$ zpool status tank | egrep -A3 'logs|cache|special'
logs
  nvme0n1p2                    ONLINE       0     0     0

Qué significa: Existe un dispositivo de log dedicado. Si es un NVMe de consumo sin PLP, puede hacer las cosas más rápidas hasta que deje de hacerlo.

Decisión: Usa SSD/NVMe empresarial con PLP para SLOG. Si no puedes, no finjas que puedes.

Tarea 8: Comprobar compresión y recordsize (palanca común de “rendimiento gratis”)

cr0x@server:~$ zfs get -o name,property,value compression,recordsize tank
NAME  PROPERTY    VALUE
tank  compression lz4
tank  recordsize  128K

Qué significa: lz4 suele ser una ganancia; recordsize 128K es un valor por defecto de propósito general.

Decisión: Para imágenes de VM, considera un dataset con recordsize=16K o 32K. Para backups/media, mantén 128K o mayor.

Tarea 9: Buscar errores de checksum (te hablan del camino, no solo del disco)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     12
            sdb     ONLINE       0     0     0

errors: No known data errors

Qué significa: Un CKSUM distinto de cero puede ser cableado, backplane, controlador, expander, firmware o el disco.
ZFS lo corrigió gracias a la redundancia, pero el camino está ruidoso.

Decisión: Revisa SMART, cambia cables, vuelve a asentar, actualiza firmware de HBA. Si los errores persisten en un disco, reemplázalo.

Tarea 10: Extraer datos SMART (solo funciona bien con acceso real a disco)

cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'model|serial|reallocated|pending|crc|temperature'
Device Model:     ST12000NM0008
Serial Number:    ZHZ1ABC1
Reallocated_Sector_Ct   0
Current_Pending_Sector  0
UDMA_CRC_Error_Count    18
Temperature_Celsius     41

Qué significa: Los errores CRC suelen gritar “cable/backplane”, no “medio del disco”.

Decisión: Arregla la capa de transporte antes de culpar a ZFS. Reemplaza cables SATA/SAS; verifica el asiento del backplane y la salud del expander.

Tarea 11: Identificar si la ruta del hipervisor está añadiendo latencia (vista guest)

cr0x@server:~$ iostat -x 1 5
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              5.0    42.0   320.0  8192.0  38.21   2.11  98.7
sdb              4.0    40.0   256.0  8064.0  41.02   2.03  97.9

Qué significa: Alto await con svctm moderado puede indicar queueing por encima del dispositivo (contención de controlador/hipervisor).

Decisión: Si esto es una VM con discos virtuales, investiga la contención del datastore del host o los ajustes de profundidad de cola; considera mover a HBA passthrough.

Tarea 12: Comprobar comportamiento TRIM/discard (importante para pools SSD y discos virtuales)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE   SOURCE
tank  autotrim  off     default

cr0x@server:~$ zpool set autotrim=on tank

Qué significa: Si estás en SSDs, autotrim ayuda el rendimiento a largo plazo. En algunas configuraciones de disco virtual, discard puede no estar soportado o ser lento.

Decisión: Habilita autotrim para pools SSD donde esté soportado; haz benchmarks en entornos virtualizados para asegurar que los trims no causen picos de latencia.

Tarea 13: Confirmar si accidentalmente estás doble-cacheando

cr0x@server:~$ zfs get -o name,property,value primarycache,secondarycache tank
NAME  PROPERTY       VALUE
tank  primarycache   all
tank  secondarycache all

Qué significa: ZFS usará RAM (ARC) y opcional L2ARC. En una VM, el host también puede cachear agresivamente.

Decisión: Si la VM tiene memoria limitada o ballooning, reduce el tamaño del ARC de ZFS o ajusta caches; evita ejecutar ZFS donde el hipervisor pueda robar su memoria de forma impredecible.

Tarea 14: Validar comportamiento de scrub y tiempo para detectar problemas

cr0x@server:~$ zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -i 'scan|scrub'
scan: scrub in progress since Sun Dec 28 01:10:11 2025
        1.23T scanned at 1.05G/s, 220G issued at 187M/s, 10.8T total
        0B repaired, 2.04% done, 0:58:12 to go

Qué significa: El throughput del scrub te habla del rendimiento de lectura extremo a extremo y la contención.

Decisión: Si los scrubs son dolorosamente lentos en una VM, revisa contención del host, queueing del controlador y si los discos virtuales están limitados por el datastore.

Tres mini-historias de la vida corporativa

1) El incidente causado por una suposición equivocada: “El hipervisor hace flush de las escrituras, obviamente”

Una empresa mediana ejecutaba un clúster ESXi con una VM de almacenamiento que daba NFS de vuelta a ESXi. La VM de almacenamiento usaba ZFS.
Alguien la montó rápido durante una ventana de refresh de hardware. Usaron VMDKs en un datastore VMFS porque hacía la construcción “portátil.”
Pasó pruebas básicas: copias de archivos, algunos boots de VM, un benchmark sintético que hizo a todos sentirse productivos.

Semanas después, un host reinició durante un evento de energía. El UPS funcionó, en su mayoría. Pero un host cayó de golpe.
Tras volver la energía, la VM de almacenamiento arrancó y ZFS importó el pool. Las aplicaciones se iniciaron y todo parecía normal—hasta que una base de datos empezó a mostrar corrupción lógica.
No “fallo de disco”, no “pool en fault”. Datos incorrectos silenciosamente en un lugar que importaba.

La investigación fue fea porque cada capa tenía negación plausible. ESXi decía que el datastore estaba sano.
ZFS decía que el pool estaba online. La base de datos decía, esencialmente, “me prometieron durabilidad y no la tuve.”
La suposición central—que las escrituras sync desde el guest eran fielmente durables en el medio físico—nunca fue validada bajo condiciones de crash.

Arreglarlo no fue ajustar un parámetro mágico de ZFS. Reconstruyeron: passthrough HBA a la VM de almacenamiento, verificaron visibilidad SMART, deshabilitaron caché de escritura insegura en el controlador y retestearon con simulaciones de crash deliberadas.
La conclusión no fue “ESXi es malo.” Fue que la abstracción sin validación convierte el “debería” en “probablemente.”
Producción no corre sobre “probablemente.”

2) La optimización que salió mal: “Vamos a añadir un L2ARC y subir la compresión”

Otra organización tenía Proxmox con ZFS en el host, mayormente SSDs más algunos mirrors HDD para almacenamiento masivo.
Tenían una queja de rendimiento: tormentas de boot de VM durante ventanas de parches causaban picos de latencia.
Alguien propuso añadir un SSD L2ARC y retocar perillas: ARC más grande, L2ARC más grande y algunos ajustes de dataset copiados de un post de foro como un hechizo.

Durante una semana, todo pareció mejorar. Las tasas de aciertos de cache subieron. Los gráficos se pusieron verdes.
Luego apareció otro síntoma: parones impredecibles durante el día. No lentitud constante—solo pausas agudas que hacían que aplicaciones con mucho chat fallaran.
Los scrubs también se ralentizaron y se extendieron a horas laborales.

Causa raíz: añadieron un SSD de consumo como L2ARC sin protección contra pérdida de energía y subestimaron la carga de escritura extra y la churn de metadatos.
Peor, la presión de memoria por un ARC sobredimensionado más demandas de memoria de VM empujó al host a comportamiento de reclaim.
El sistema no se quedó sin RAM; se quedó sin RAM estable. La efectividad de la cache de ZFS se desplomó cada vez que el host tuvo que hacer malabares.

Revirtieron el L2ARC, limitaron el ARC razonablemente y se enfocaron en el cuello de botella real: comportamiento de escrituras sync y queueing durante picos.
Añadieron un SLOG apropiado y ajustaron el almacenamiento de VM para repartir picos de IO.
La “optimización” no era mala—solo estaba mal aplicada. El tuning de ZFS es un bisturí, no confeti.

3) La práctica aburrida pero correcta que salvó el día: burn-in consistente + líneas base SMART + calendario de scrubs

Un equipo con cargas mixtas en Proxmox tenía una costumbre que parecía casi anticuada: cada disco nuevo pasaba un burn-in.
No un formateo rápido. Uno real—tests SMART largos, badblocks y una instantánea base de atributos SMART.
Luego añadían cada disco al pool solo después de que sobreviviera un fin de semana de estrés.

Meses después, empezaron a ver errores de checksum ocasionales en un vdev. Nada dramático. ZFS los corregía.
Pero su monitorización marcó un aumento en UDMA CRC en un solo disco, y la línea base dejó claro: no “siempre fue así.”
Cambiaron el cable y los errores pararon.

Dos semanas después, otro disco mostró aumento de sectores realocados. De nuevo: la comparación con la línea base hizo la tendencia inequívoca.
Reemplazaron el disco en horario laboral, resilver limpio, y nadie fuera de infra lo notó.

La magia no fue una arquitectura elegante. Fue higiene repetitiva y disciplinada: scrubs, monitorización de tendencias SMART y no confiar en discos recién sacados de la caja.
Las prácticas aburridas no reciben aplausos. Evitan que los aplausos se sustituyan por gritos.

Guía rápida de diagnóstico

Cuando “ZFS está lento” llega a tu cola, necesitas un camino a una respuesta en minutos, no un fin de semana de tuning por sensaciones.
Esta guía asume que quieres identificar el cuello de botella rápidamente y decidir si es un problema de disco/controlador, de sync/flush o de capas de virtualización.

Primero: identifica la ruta de presentación del almacenamiento

• ¿ZFS está en el host Proxmox? ¿O dentro de una VM (ESXi o Proxmox)?
• ¿El sistema ZFS ve discos reales con seriales? (lsblk, smartctl)
• ¿Hay un controlador RAID haciendo “caché útil”?

Segundo: separa latencia de throughput

• Usa iostat -x para ver await y %util por dispositivo.
• Usa una prueba de escritura sync (dd ... oflag=dsync) para ver si el dolor es específico de sync.
• Revisa salud del pool (zpool status) por errores que impliquen reintentos.

Tercero: busca queueing y contención por encima de los discos

• En una VM: comprueba si el datastore del host está saturado o existen cadenas de snapshots.
• Verifica si ARC de ZFS está thrasheando por ballooning de VM o presión del host.
• Confirma que no estás ejecutando un scrub/resilver durante ventanas de IO pico.

Cuarto: decide la clase de solución

• Solución de diseño: mover de VMDKs/RDM a HBA passthrough, añadir SLOG/dispositivos de metadata, reconstruir con ashift correcto.
• Solución operativa: reemplazo de cables/firmware, ajustar calendario de scrubs, limitar ARC.
• Solución de expectativas: la carga es IO random sync en discos mecánicos; la física dice “no.” Añade SSDs o cambia arquitectura.

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

1) Síntoma: Picos de latencia aleatorios, especialmente durante snapshots/backups

Causa raíz: Pool ZFS construido sobre VMDKs con cadenas de snapshots en el hipervisor, causando IO extra de metadatos y operaciones de copia.

Solución: Evita snapshots del hipervisor para VMs de almacenamiento; usa snapshots/replicación de ZFS en su lugar. Prefiere HBA passthrough para que el pool no sea un conjunto de VMDKs.

2) Síntoma: ZFS reporta errores de checksum, pero SMART se ve limpio

Causa raíz: Problemas de transporte (cable SAS/SATA, backplane, expander, conector marginal) o quirks de firmware del controlador.

Solución: Revisa errores CRC, cambia cables, vuelve a asentar discos, actualiza firmware de HBA y asegura refrigeración adecuada para HBAs y expanders.

3) Síntoma: Escrituras sync dolorosamente lentas; async parece bien

Causa raíz: No hay SLOG para cargas sync intensas, o semánticas de caché/flush provocan flushes forzados que bloquean.

Solución: Añade un dispositivo SLOG empresarial con PLP; verifica que la caché del controlador sea segura; valida con dd oflag=dsync y pruebas específicas de la carga.

4) Síntoma: El pool importa lentamente o los dispositivos “se mueven” tras reboot

Causa raíz: Nombres de dispositivo inestables (usar /dev/sdX), especialmente en entornos virtualizados o con expanders.

Solución: Usa /dev/disk/by-id al crear vdevs y al reemplazar discos; documenta el mapeo slot-serial.

5) Síntoma: Números de benchmark geniales, rendimiento de aplicaciones pésimo

Causa raíz: El benchmark mide caché (ARC/caché del host), no disco. O mide throughput secuencial mientras la app es IO aleatorio.

Solución: Prueba con patrones sync/aleatorios relevantes para la app; mira métricas de latencia, no solo MB/s; limita ARC para evitar peleas por memoria en el host.

6) Síntoma: Tras pérdida de energía, el pool ZFS está online pero las apps muestran corrupción

Causa raíz: Los reconocimientos de escritura no fueron durables (caché insegura, desajuste de flush en la virtualización), causando escrituras partidas o perdidas fuera de la conciencia de ZFS.

Solución: Usa HBA passthrough, deshabilita cachés volátiles sin protección, valida consistencia tras crash y usa SLOG apropiado para cargas sync.

7) Síntoma: Rendimiento del pool SSD decae con el tiempo

Causa raíz: TRIM/discard no funciona a través de la pila; alta fragmentación y sin reclamación.

Solución: Habilita autotrim en ZFS donde sea soportado; asegura que la ruta de disco virtual pase discard; si no, programa trim manual o rediseña.

8) Síntoma: Resilver tarda una eternidad e impacta todo

Causa raíz: Pool casi lleno, discos lentos y virtualización añade contención. O estás resilverando a través de un controlador/expander limitado.

Solución: Mantén pools con margen de espacio sensato, prefiere mirrors para cargas IOPS intensivas, programa resilvers/scrubs fuera de horas pico y evita HBAs sobre suscrito.

Listas de verificación / plan paso a paso

Checklist de diseño: elegir la ruta del controlador

1. Decide dónde vive ZFS: Host Proxmox (preferido para shops Proxmox-first) o VM de almacenamiento (común para shops ESXi-first).
2. Si ZFS está en una VM: exige passthrough PCIe de HBA salvo que puedas justificar los tradeoffs de monitorización e integridad.
3. Elige HBA: HBA SAS en modo IT; evita firmware RAID y cachés volátiles.
4. Planifica monitorización: SMART, alertas de zpool, calendario de scrubs y mapeo serial-a-bahía.
5. Plan de recuperación: ¿puedes mover discos/HBA a otro host e importar?

Checklist de implementación: ZFS en host Proxmox

1. Configura BIOS a AHCI para SATA onboard; habilita IOMMU si necesitas passthrough para otros dispositivos.
2. Instala Proxmox; verifica que los discos muestren modelos/seriales reales en lsblk.
3. Crea el pool con rutas by-id; verifica ashift antes de comprometerte.
4. Habilita compresión (lz4) y ajusta recordsize del dataset por carga.
5. Configura calendario de scrubs y monitorización SMART.

Checklist de implementación: ESXi con VM de almacenamiento ZFS

1. Instala una HBA en modo IT; confirma que está en su propio grupo IOMMU y soportada para passthrough.
2. Habilita passthrough en el host ESXi y adjunta la HBA a la VM de almacenamiento.
3. En la VM, confirma que el driver de la HBA carga y los discos aparecen con números de serie.
4. Crea el pool ZFS directamente sobre los discos; configura scrubs periódicos y checks SMART.
5. Exporta almacenamiento de vuelta a ESXi vía NFS/iSCSI; mide el comportamiento sync según tus cargas.
6. Documenta las restricciones operativas: no habrá vMotion para esa VM; el parcheo requiere planificación.

Checklist de ops: higiene aburrida mensual

1. Revisa zpool status por errores y resilvers lentos.
2. Revisa deltas SMART: realocados, pendientes, errores CRC, temperaturas.
3. Confirma que los scrubs se completan dentro de ventanas esperadas.
4. Valida margen de espacio libre y riesgos de fragmentación.
5. Prueba restauraciones (a nivel archivo y VM) como si importara.

Preguntas frecuentes

¿Es obligatorio el passthrough de HBA para ZFS en una VM?

¿Obligatorio? No. ¿Recomendado para producción donde te importa integridad de datos, monitorización y recuperación predecible? Sí.
Los discos virtuales pueden funcionar, pero aceptas puntos ciegos y modos de fallo más complejos.

¿Es RDM “suficiente” en ESXi?

A veces. Normalmente es mejor que VMDKs para presentar discos, pero sigue sin ser tan limpio como passthrough HBA.
La gran pregunta es si el guest puede ver errores y SMART de forma fiable y si las semánticas de flush se comportan bajo estrés.

¿Puedo poner ZFS encima de un controlador RAID?

Puedes, en el mismo sentido en que puedes remolcar un barco con un coche deportivo: puede moverse y creará historias.
Para la redundancia de ZFS, usa comportamiento JBOD/HBA para que ZFS maneje redundancia y reparación.

¿Por qué la gente dice que ZFS necesita “acceso directo al disco”?

Porque el modelo de autocuración e integridad de ZFS es más fuerte cuando puede ver errores reales del dispositivo y controlar orden/durabilidad.
Las capas de abstracción pueden ocultar las señales que ZFS usa para diagnosticar y reparar.

¿Qué controlador virtual es mejor si debo usar discos virtuales?

En guests Linux, paravirtual SCSI (donde esté disponible) suele comportarse mejor que controladores emulados antiguos.
En Proxmox, virtio-scsi tiende a ser la opción sensata por defecto. Pero recuerda: la elección de controlador no puede restaurar la visibilidad SMART perdida por los VMDKs.

¿ZFS dentro de una VM elimina la necesidad de un SAN/NAS?

Puede reemplazarlo para algunos entornos—especialmente PYMEs—si tratas la VM de almacenamiento como un appliance real:
ruta hardware dedicada, upgrades disciplinados, restores probados y límites claros del dominio de fallo.

¿Debo ejecutar ZFS en el host Proxmox o en una VM?

En Proxmox: ejecuta ZFS en el host salvo que tengas una razón contundente para no hacerlo. Es más simple y más observable.
Si necesitas el conjunto de funciones de un appliance de almacenamiento (servicios NAS, ecosistema de apps) y aceptas la complejidad, el enfoque en VM puede funcionar.

¿Cómo sé si las escrituras sync son el cuello de botella?

Si las bases de datos o cargas NFS se detienen y tus benchmarks async se ven bien, prueba el comportamiento sync con dd oflag=dsync y observa la latencia.
Si sync es lento, considera SLOG con PLP y verifica políticas de caché.

¿Cuál es la mayor señal de alerta en una revisión de diseño de virtualización para ZFS?

Una VM de almacenamiento ejecutando ZFS sobre VMDKs thin-provisioned con snapshots del hipervisor habilitados y sin monitorización clara de la ocupación del datastore.
Es una máquina de outage en cámara lenta.

¿El passthrough de HBA previene toda la corrupción?

No. Reduce capas que pueden mentir sobre durabilidad y mejora la visibilidad de errores.
Aún necesitas redundancia, scrubs, monitorización SMART, respaldos probados y procesos operativos sensatos.

Pasos prácticos siguientes

Si estás construyendo desde cero y ZFS es central: elige la arquitectura que permita a ZFS ver y controlar los discos.
En Proxmox, eso normalmente significa ZFS en el host con una HBA real (o SATA AHCI) y sin ingenios de RAID.
En ESXi, eso normalmente significa una HBA dedicada pasada a una VM de almacenamiento, con el almacenamiento exportado luego por NFS/iSCSI.

Si ya desplegaste ZFS sobre discos virtuales en producción: no te asustes, pero deja de improvisar.
Ejecuta las tareas de diagnóstico arriba, valida el comportamiento de escrituras sync, comprueba si puedes ver SMART y decide si el perfil de riesgo coincide con tu negocio.
Luego programa la migración a passthrough HBA como cualquier proyecto de reducción de riesgo: deliberado, probado y con plan de rollback.

La ruta del controlador no es un detalle cosmético. Es la diferencia entre ZFS siendo un narrador fiable y ZFS atrapado en el asiento trasero con los ojos vendados.
Déjalo conducir.