Almacenamiento en Proxmox: ZFS vs LVM-Thin — La mentira de los benchmarks que te hace perder semanas

La mentira del benchmark: por qué tu almacenamiento “más rápido” pierde en producción

La mayoría de los debates sobre almacenamiento en Proxmox comienzan con una captura de pantalla de resultados de fio, como si el almacenamiento fuera una carrera de aceleración y el ganador se quedara con tus VMs. El problema es que el almacenamiento para virtualización rara vez está limitado por el “máximo rendimiento” en un sistema limpio y vacío. Está limitado por la latencia bajo I/O mixto, el comportamiento de colas, la amplificación de escritura y lo que ocurre cuando un pool está al 80% y alguien toma una instantánea cada hora.

Los benchmarks suelen mentir en cuatro formas comunes:

1) Evalúan la capa equivocada

fio en el dispositivo de bloque del host no es lo mismo que fio dentro de un invitado con un disco virtual encima de una pila de almacenamiento con caché, copy-on-write, discard y semánticas de flush. Proxmox añade elecciones también: raw vs qcow2, cache=none vs writeback, aio=native vs io_uring, VirtIO SCSI vs VirtIO Block. Eso antes de que siquiera elijas ZFS o LVM-Thin.

2) Ignoran escrituras síncronas y flushes

Las bases de datos, servidores de correo y todo lo que se preocupa por la durabilidad emitirán flushes (o usarán O_DIRECT / comportamiento tipo FUA según la pila). ZFS tiene opiniones explícitas sobre escrituras síncronas. LVM-Thin en su mayoría delega la durabilidad al sistema de ficheros subyacente (a menudo ext4/xfs) y a la política de caché de la unidad. Si tu benchmark no incluye patrones síncronos, no estás evaluando producción. Estás evaluando optimismo.

3) No incluyen fragmentación y snapshots

Las cadenas de snapshots de LVM-Thin y las instantáneas de ZFS se comportan de forma diferente, pero ambas pueden convertir “rápido” en “¿por qué la latencia es 200 ms?” cuando las snapshots se acumulan o los bloques se dispersan. El secreto sucio: la primera semana después del despliegue siempre es la más rápida. Probablemente tu benchmark midió la semana uno.

4) Miden promedios, no latencia de cola

Tus usuarios no experimentan la latencia promedio. Experimentan p95 y p99. Experimentan la consulta que se queda esperando detrás de una cola de escrituras. Para almacenamiento de VMs, la latencia de cola es la diferencia entre “bien” e “incidente”.

Vale la pena colgar una cita encima de tus paneles. Es corta, ruda y correcta:

“El código más rápido es el código que no ejecutas.” — Ken Thompson

Versión para almacenamiento: la I/O más rápida es la I/O que no fuerzas a un camino caro. Elige un backend de almacenamiento que coincida con la forma de tu I/O y la tolerancia a fallos para que no estés “ejecutando” dolor innecesario.

Primera broma corta: Los benchmarks de almacenamiento son como los currículums: los mejores son técnicamente verdaderos y aun así tremendamente engañosos.

Hechos e historia breve que realmente importan

Esto no es trivia. Explican por qué ZFS y LVM-Thin se comportan como lo hacen, y por qué sus modos de fallo se sienten tan distintos.

1. ZFS fue diseñado para acabar con la corrupción de datos silenciosa combinando sistema de ficheros y gestión de volúmenes con checksums en cada bloque. Ese ADN todavía se nota: integridad primero, rendimiento segundo y “depende” tercero.
2. Copy-on-write es más antiguo que la mayoría de tus servidores. El concepto precede a la virtualización moderna; ZFS lo operacionaliza a escala. Es por eso que las snapshots son baratas y por qué las escrituras aleatorias pueden volverse más caras con el tiempo.
3. LVM existía antes que la provisión delgada. LVM clásico era thick por defecto: asignabas lo que usabas. Thin llegó después para competir con el comportamiento de los SAN y la comodidad de la virtualización.
4. La provisión delgada se hizo popular porque el almacenamiento era caro, no porque fuera seguro. El sobreaprovisionamiento ayuda a los presupuestos. También ayuda a que los incidentes ocurran a las 2 a.m.
5. Barreras de escritura y semánticas de flush evolucionaron porque los discos mentían. Las unidades con caché de escritura volátil pueden reconocer escrituras antes de que sean duraderas. Los sistemas de ficheros y las pilas de almacenamiento añadieron barreras/flushes para reducir esas mentiras. Funciona—hasta que una capa lo ignora.
6. ARC de ZFS se creó cuando la RAM era un bien escaso. ARC es agresivamente adaptativo y usará memoria si se lo permites. En un hypervisor, eso puede chocar con las necesidades de memoria de las VMs a menos que establezcas límites.
7. Los SSD cambiaron el cuello de botella pero no las leyes físicas. La latencia mejoró; la cola sigue existiendo. El I/O aleatorio mixto sigue siendo un recaudador de impuestos, solo con una calculadora más rápida.
8. NVMe de consumo introdujo nuevos patrones de fallo. Throttling térmico, rarezas de firmware y picos súbitos de latencia pueden parecer “ZFS lento” o “LVM lento” cuando el culpable real es la unidad comportándose como una estrella de drama.

Marco de decisión: elige un valor por defecto y justifícalo

Si ejecutas Proxmox en producción, necesitas una elección por defecto que sobreviva al caos ordinario: crecimiento inesperado, backups, snapshots, humanos cansados y un CFO que piensa “almacenamiento es almacenamiento”.

Mi valor por defecto con opinión

• Nodo único o clúster pequeño con discos locales, sin SAN externo: elige ZFS a menos que tengas una razón muy específica para no hacerlo.
• Tienes planificación de capacidad estable, quieres rendimiento predecible y te sientes cómodo con la gestión clásica de bloque + sistema de ficheros: LVM-Thin está bien—si tratas el sobreaprovisionamiento como un arma cargada.
• Optimizas para flujos de trabajo de snapshot/backup de VMs que “simplemente funcionan” con seguridad razonable: ZFS suele ser el valor por defecto más seguro.

Cuando ZFS es el mejor compromiso

• Te importa checksum de extremo a extremo y la detección fácil de bit rot.
• Valoras semánticas simples de replicación (send/receive) y snapshots coherentes.
• Puedes asignar RAM adecuadamente y aceptas cierta sobrecarga por seguridad.
• Sabes diseñar vdevs correctamente (mirrors para IOPS; RAIDZ para capacidad, con salvedades).

Cuando LVM-Thin es el mejor compromiso

• Necesitas sobrecarga mínima y estás sobre hardware rápido y fiable debajo (buenos SSDs, controlador RAID con BBWC, o NVMe enterprise con PLP).
• Quieres modelos mentales más simples: dispositivos de bloque, ext4/xfs y herramientas Linux bien conocidas.
• Estás dispuesto a aplicar monitoreo estricto sobre el uso de datos y metadata del thin pool, y tienes un plan para “pool lleno” que no sea “pánico”.

La pregunta que decide la mayoría de los casos

¿Cuál es el costo de equivocarse? Con ZFS, equivocarse suele aparecer como sorpresas de rendimiento y contención de memoria. Con LVM-Thin, equivocarse suele aparecer como incidentes de capacidad que pueden convertirse en pérdidas de datos si dejas que un thin pool llegue al 100% o que la metadata se llene.

Elige tu veneno según lo que tu equipo pueda manejar operativamente a las 3 a.m. Eso no es cinismo; es ingeniería de fiabilidad.

ZFS en Proxmox: lo que realmente le hace a tu I/O

ZFS es un sistema de almacenamiento, no un sistema de ficheros pegado

ZFS maneja las decisiones de la capa de bloque: asignación, caché, checksumming, compresión y cómo las escrituras se vuelven durables. Esa integración es la razón por la que ZFS puede proteger datos mejor que las pilas “sistema de ficheros sobre RAID”. También es la razón por la que el rendimiento de ZFS depende mucho de cómo configuras el pool y los datasets, no solo de los discos.

Mirrors vs RAIDZ: la realidad de IOPS

Para almacenamiento de VMs, los IOPS aleatorios y la latencia importan. Los mirrors generalmente ganan aquí porque pueden atender lecturas desde cualquiera de los lados y distribuir mejor el I/O aleatorio. RAIDZ es excelente para eficiencia de capacidad, pero las escrituras pequeñas aleatorias pueden ser caras debido a la aritmética de paridad y al comportamiento read-modify-write.

Si ejecutas muchas VMs pequeñas con cargas mixtas, los mirrors son la respuesta aburrida y correcta. RAIDZ puede estar bien para almacenamiento masivo o cargas secuenciales, pero el “caos misceláneo” de VMs tiende a castigarlo.

ARC: tu amigo hasta que deja de serlo

El ARC (Adaptive Replacement Cache) usará RAM agresivamente. En una caja dedicada de almacenamiento eso es genial. En un hypervisor, compite con la memoria de las VMs. Privar al host y obtienes swapping, ballooning y jitter en VMs que parece latencia de almacenamiento.

La solución es simple: capar ARC para dejar espacio para VMs y el host. La parte difícil es admitir que tu plan “128GB RAM es suficiente” no incluyó el comportamiento de caché.

Escrituras síncronas: el benchmark de producción que olvidaste

ZFS trata las escrituras síncronas como sagradas: si la aplicación dice “esto debe ser durable”, ZFS lo respetará. Sin un dispositivo de registro de baja latencia dedicado (SLOG) y características de dispositivo apropiadas (la protección frente a pérdida de energía importa), las cargas con muchas escrituras síncronas pueden volverse más lentas de lo esperado.

También existe la tentación de ajustar sync=disabled. Hace que los benchmarks exploten. También cambia las semánticas de durabilidad. Activarlo globalmente es como sustituir los cinturones de seguridad por pósters motivacionales.

Compresión: normalmente una ganancia, a veces una trampa

Las CPUs modernas a menudo hacen que la compresión sea efectivamente “gratis” comparada con los costes de I/O, especialmente en SSDs. lz4 suele ser el valor por defecto correcto. Pero la compresión puede aumentar la contención de CPU en hosts sobrecargados, y puede distorsionar los benchmarks si tus datos de prueba se comprimen mejor que los reales. Los datos aleatorios no se comprimirán; las imágenes de VM y los logs a menudo sí.

ZVOL vs imágenes basadas en archivos

En Proxmox, el almacenamiento ZFS a menudo significa ZVOLs (dispositivos de bloque) para discos de VM. Eso suele ser bueno para la consistencia de rendimiento. Pero la sintonización importa: volblocksize afecta la amplificación de escritura y la latencia. Equivocarte y puedes crear un impuesto de rendimiento que pagarás para siempre, porque cambiarlo después no es trivial.

LVM-Thin en Proxmox: la eficiencia silenciosa y los bordes afilados

LVM-Thin no es “un ZFS peor”

LVM-Thin es una capa de bloque con provisión delgada. No proporciona checksums de extremo a extremo. No te protege inherentemente de la corrupción silenciosa. No intenta ser una religión del almacenamiento. Es una herramienta pragmática que funciona extremadamente bien cuando le das un almacenamiento subyacente estable y respetas sus modos de fallo.

La gran ventaja: simplicidad y baja sobrecarga

En buen hardware, LVM-Thin puede ser muy rápido. Hay menos malabarismos de metadata que en un sistema copy-on-write que hace checksums, compresión y semánticas transaccionales. Si quieres un comportamiento predecible, “clásico Linux”, LVM-Thin es territorio cómodo.

El problema de “pool thin lleno” no es teórico

La provisión delgada es genial hasta que deja de serlo. Cuando el área de datos del thin pool se llena, las escrituras fallan. Cuando la metadata del thin pool se llena, puedes obtener stalls y fallos que parecen corrupción o “VM congelada”. Y como es virtualización, puedes llenar el pool de maneras que no son obvias—snapshots, trabajos de backup o una sola VM escribiendo logs como si le pagaran por línea.

El sobreaprovisionamiento está permitido, pero es un presupuesto de riesgo. Gástalo deliberadamente, monitorízalo agresivamente.

Discard/TRIM: útil, pero solo si es de extremo a extremo

LVM-Thin puede reclamar bloques si los discards atraviesan desde el invitado al host. Pero la cadena es larga: sistema de ficheros invitado → controlador de disco virtual → ajustes de QEMU → pila de bloque del host → thin pool. Fallar en un eslabón y tu “usado” del thin pool crece para siempre, incluso cuando los invitados eliminan datos.

Snapshots: convenientes, pero no las acumules

Las snapshots de LVM (thin snapshots) son funcionales y rápidas al principio. Con el tiempo, muchas snapshots pueden aumentar el trabajo de metadata y fragmentar el pool. Esto no es exclusivo de LVM; es una verdad general en entornos con muchas instantáneas. Pero la presión sobre la metadata de thin es un filo particularmente afilado: falla de forma ruidosa.

Segunda broma corta: La provisión delgada es como el café gratis en la oficina: a la gente le encanta hasta que se acaba, y entonces de repente es la emergencia de todos.

Benchmarks que no mienten (tanto): qué medir en su lugar

Si quieres benchmarks que se correlacionen con el dolor en producción, mide estas cosas en lugar de solo el máximo rendimiento:

• Latencia de cola (p95/p99) bajo I/O mixto, no solo IOPS promedio.
• Latencia de escrituras síncronas (o patrones con muchos flushes) si ejecutas bases de datos, correo o apps con journaling intensivo.
• Rendimiento bajo carga de snapshot/backup porque es cuando los usuarios se quejan.
• Comportamiento al 70–85% de llenado porque nadie mantiene pools vacíos para siempre.
• Coste de CPU por I/O porque los hypervisors también ejecutan cómputo.

Usa el invitado para la experiencia del usuario, usa el host para la causa raíz

Ejecuta pruebas específicas de carga dentro de una VM para aproximar lo que siente el usuario. Luego usa herramientas a nivel host para explicar el comportamiento: ¿es el disco, la cola, la CPU, el ARC o la metadata del thin?

También: no hagas benchmarks con cachés vacías a menos que planees reiniciar cada hora. Las pruebas con caché fría son útiles, pero no cuentan toda la historia.

Guía de diagnóstico rápido: encuentra el cuello de botella antes de que empiece la reunión

Este es el orden que normalmente te lleva a la verdad rápidamente en Proxmox. No siempre. Pero suficientemente seguido como para convertirlo en hábito.

Primero: ¿realmente es almacenamiento?

• Comprueba la presión de CPU del host tipo steal/ready: la saturación puede parecer esperas de I/O.
• Comprueba la presión de memoria y el swapping: un hypervisor que hace swapping produce tickets de “latencia de almacenamiento”.
• Comprueba la red si es almacenamiento remoto (iSCSI/NFS/Ceph): retransmisiones y pausas parecen stalls de disco.

Segundo: localiza la cola

• Busca iowait y utilización por dispositivo.
• Comprueba si hay un solo disco/vdev caliente, o una sola VM haciendo I/O patológico.
• Correlaciona con jobs de snapshot/backup y replicación.

Tercero: identifica el modo de fallo específico de la pila de almacenamiento

• ZFS: presión de ARC, cuellos de botella en escrituras síncronas, fragmentación del pool, vdev lento, recordsize/volblocksize mal dimensionado, o malas elecciones de SLOG.
• LVM-Thin: datos/metadata del thin pool cerca del lleno, discard que no funciona, dispersión de snapshots, problemas de política de caché del filesystem/RAID subyacente.

Cuarto: verifica con una prueba dirigida

No ejecutes un benchmark masivo en medio de un incidente. Ejecuta una prueba pequeña y representativa: mide latencia, no héroes de throughput. Si no puedes explicar los números en términos de la pila, los números son solo decorativos.

Tareas prácticas: comandos, salidas y qué decisión disparan

Estas son las tareas que realmente hago en hosts Proxmox cuando alguien dice “el almacenamiento está lento” o “necesitamos elegir ZFS vs LVM-Thin.” Cada una incluye lo que significa la salida y la decisión que tomas a partir de ello.

Task 1: Identify what storage a VM disk is actually using

cr0x@server:~$ qm config 101 | egrep '^(boot|scsi|virtio|ide|sata)'
boot: order=scsi0;net0
scsi0: local-zfs:vm-101-disk-0,size=80G

Qué significa: El disco de esta VM está en local-zfs. Investigas ZFS, no LVM, no “el SSD”.

Decisión: Usa las herramientas ZFS (zpool/zfs) y rutas de sintonía de ZVOL, y espera semánticas de snapshot nativas de ZFS.

Task 2: Check host memory pressure (ARC vs VMs vs swap)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        92Gi       3.1Gi       1.2Gi        30Gi        14Gi
Swap:          8.0Gi       2.6Gi       5.4Gi

Qué significa: Hay swap en uso. En un hypervisor, eso es un olor a rendimiento. Si usas ZFS, ARC puede ser parte de la historia; si no, las VMs pueden estar sobreasignadas.

Decisión: Investiga el tamaño de ARC (/proc/spl/kstat/zfs/arcstats) y el swapping del host. Considera capar ARC o ajustar la memoria de las VMs/política de ballooning.

Task 3: Check I/O wait and top offenders

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.11-8-pve (server) 	02/04/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.21    0.00    4.13   21.77    0.00   65.89

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
nvme0n1         120.0   18000.0     0.0   0.00    3.20   150.0    640.0   72000.0     0.0   0.00   28.40   112.5   18.40  99.00

Qué significa: %iowait es alto y nvme0n1 está al ~99% de utilización con un alto write await. Eso es un problema de cola de almacenamiento, no “la UI de Proxmox está lenta”.

Decisión: Identifica qué VMs están generando escrituras; luego determina si es carga esperada, un solo infractor o una mala configuración (escrituras síncronas, snapshots, problemas de thin pool).

Task 4: See which processes are issuing I/O (host view)

cr0x@server:~$ pidstat -d 1 5
Linux 6.5.11-8-pve (server) 	02/04/2026 	_x86_64_	(32 CPU)

02:14:21      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
02:14:22        0      2310      0.00  82000.00      0.00       90  kworker/u64:2
02:14:22        0     12844      0.00  12000.00      0.00       30  qemu-system-x86

Qué significa: QEMU está escribiendo; un kworker del kernel también está activo (podría ser filesystem, txg de ZFS, md/raid, o housekeeping de NVMe dependiendo de la pila).

Decisión: Mapea el PID de QEMU a un ID de VM y luego inspecciona el disco y la carga de esa VM. Si se correlaciona con jobs de backup, cambia horarios o limita ancho de banda de backups.

Task 5: Map QEMU processes to VM IDs

cr0x@server:~$ pgrep -a qemu-system | head -n 2
12844 /usr/bin/kvm -id 101 -name vm101 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server=on,wait=off ...
13201 /usr/bin/kvm -id 102 -name vm102 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server=on,wait=off ...

Qué significa: PID 12844 es la VM 101. Ahora puedes correlacionar el infractor con un tenant/equipo/aplicación.

Decisión: Revisa la configuración de almacenamiento de la VM 101 y cualquier snapshot/backup en ejecución para ella.

Task 6: For ZFS, check pool health and basic stats

cr0x@server:~$ zpool status -x
all pools are healthy

Qué significa: No hay fallos de dispositivo evidentes. Eso no significa que el rendimiento sea bueno; significa que no tienes un vdev degradado que arrastre la latencia.

Decisión: Pasa a contadores de rendimiento: zpool iostat, ARC y comportamiento síncrono.

Task 7: For ZFS, locate the slow vdev/disk

cr0x@server:~$ zpool iostat -v rpool 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool        2.10T  1.30T    420   1800  32.4M   140M
  mirror     1.05T   650G    210    900  16.2M  70.0M
    nvme0n1      -      -    105    460  8.10M  35.1M
    nvme1n1      -      -    105    440  8.10M  34.9M
  mirror     1.05T   650G    210    900  16.2M  70.0M
    nvme2n1      -      -    200    900  15.9M  70.0M
    nvme3n1      -      -     10      0  0.30M  0.00M

Qué significa: Un dispositivo (nvme3n1) está contribuyendo casi nada. Eso sugiere un problema de dispositivo, problema de ruta o un desequilibrio de vdev debido a errores.

Decisión: Revisa zpool status en detalle, logs del kernel y SMART de NVMe. Un pool “saludable” puede tener un disco comportándose mal antes de disparar un fallo crítico.

Task 8: For ZFS, see ARC size and hit ratio signals

cr0x@server:~$ awk '/c_max|c_min|size/{print}' /proc/spl/kstat/zfs/arcstats | head
c_max 4 85899345920
c_min 4 10737418240
size 4 64424509440

Qué significa: ARC max es ~80GiB, actual ~60GiB. En un hypervisor, eso puede estar bien—o puede estar robando memoria a las VMs.

Decisión: Si el host está haciendo swap o las VMs hacen balloon inesperadamente, capa ARC. Si el host tiene memoria libre y el almacenamiento es el cuello de botella, ARC puede estar ayudando; no lo “optimices” hacia una regresión.

Task 9: For ZFS, check dataset/ZVOL settings that affect VM I/O

cr0x@server:~$ zfs get -r compression,atime,recordsize,sync rpool/data | head -n 20
NAME        PROPERTY     VALUE     SOURCE
rpool/data  compression  lz4       local
rpool/data  atime        off       local
rpool/data  recordsize   128K      default
rpool/data  sync         standard  default

Qué significa: Valores predeterminados sensatos: lz4, atime=off, recordsize 128K (nota: para ZVOLs, la perilla relevante es volblocksize por ZVOL).

Decisión: Si las cargas son intensivas en bases de datos con muchas escrituras de 8K, considera ajustar por dataset o por ZVOL en lugar de cambios globales. Evita cambios “mágicos” globales durante incidentes.

Task 10: For ZFS sync behavior, verify if you have a SLOG and what it is

cr0x@server:~$ zpool status rpool | sed -n '1,80p'
  pool: rpool
 state: ONLINE
config:

	NAME        STATE     READ WRITE CKSUM
	rpool       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    nvme0n1 ONLINE       0     0     0
	    nvme1n1 ONLINE       0     0     0
	logs
	  nvme4n1p1 ONLINE       0     0     0

errors: No known data errors

Qué significa: Hay un dispositivo de log dedicado. Eso puede cambiar drásticamente la latencia de escrituras síncronas—si el dispositivo es de baja latencia y tiene protección frente a pérdida de energía.

Decisión: Si las cargas síncronas son lentas, revisa la salud/latencia del dispositivo de log. Si no tienes SLOG y ejecutas apps síncronas, considera añadir hardware adecuado en lugar de apagar sync.

Task 11: For LVM-Thin, check thin pool data and metadata usage

cr0x@server:~$ lvs -a -o+seg_monitor,lv_size,data_percent,metadata_percent,lv_attr vg0
  LV                 VG  Attr       LSize   Data%  Meta%  Mon
  pve                vg0 -wi-ao----  200.00g
  data               vg0 twi-aotz--    3.00t  78.34  62.11 yes
  [data_tdata]       vg0 Twi-ao----    3.00t
  [data_tmeta]       vg0 ewi-ao----   16.00g
  [lvol0_pmspare]    vg0 ewi-------   16.00g

Qué significa: El thin pool data está al 78% de uso de datos y 62% de uso de metadata. Eso es aceptable pero en tendencia hacia “vigilar”. La metadata se llena más rápido con snapshots.

Decisión: Si Meta% sube rápido, reduce la proliferación de snapshots, asegúrate de que discard funcione y planifica la expansión de metadata antes de chocar con un muro.

Task 12: For LVM-Thin, confirm monitoring and auto-extension behavior

cr0x@server:~$ lvs -o lv_name,seg_monitor vg0
  LV    Monitor
  data  monitored

Qué significa: El thin pool está monitorizado (dmeventd). Eso es bueno: puedes disparar advertencias/políticas de auto-extensión.

Decisión: Si no está monitorizado, arréglalo inmediatamente. Los thin pools que se llenan en silencio son cómo terminas explicando a gestión por qué “sobrecommit de almacenamiento” no es dinero gratis.

Task 13: Check discard support end-to-end (host side)

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,ROTA,TYPE,MOUNTPOINT | head
NAME        DISC-GRAN DISC-MAX ROTA TYPE MOUNTPOINT
nvme0n1       512B       2G    0 disk
├─nvme0n1p1   512B       2G    0 part
└─nvme0n1p2   512B       2G    0 part

Qué significa: El dispositivo de bloque reporta granularidad y máximo de discard, lo que sugiere que TRIM es soportado a nivel de unidad.

Decisión: Si DISC-* está en blanco o cero, discard puede no funcionar (o estar oculto por RAID). Para provisión delgada, eso aumenta la probabilidad de que “el espacio usado nunca disminuya”.

Task 14: Confirm VM disk cache mode and discard settings (Proxmox/QEMU)

cr0x@server:~$ qm config 101 | egrep '^(scsi0|virtio0|ide0|sata0)'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,cache=none,size=80G

Qué significa: discard=on está activado (bueno para thin), cache=none evita doble caché y respeta semánticas de flush de forma más predecible, y iothread=1 puede reducir la contención en discos muy ocupados.

Decisión: Si discard está desactivado y dependes de provisión delgada, actívalo (y verifica dentro del invitado). Si cache=writeback se usa a la ligera, verifica que no estés intercambiando seguridad por velocidad sin darte cuenta.

Task 15: Check kernel log for device resets and NVMe drama

cr0x@server:~$ dmesg -T | egrep -i 'nvme|reset|timeout|blk_update_request|I/O error' | tail -n 8
[Tue Feb  4 02:08:10 2026] nvme nvme3: I/O 123 QID 4 timeout, reset controller
[Tue Feb  4 02:08:11 2026] nvme nvme3: controller reset successful

Qué significa: El dispositivo está haciendo timeout y reseteando. Eso puede presentarse como picos de latencia aleatorios que se culpan a ZFS o LVM.

Decisión: Trata esto primero como hardware/firmware. No ajustes ZFS recordsize para arreglar un reset de controlador. Reemplaza o actualiza, y luego reevalúa.

Task 16: Check pool fullness and fragmentation (ZFS)

cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,frag,health
NAME   SIZE  ALLOC   FREE  CAPACITY  FRAG  HEALTH
rpool  3.40T  2.10T  1.30T       61%   38%  ONLINE

Qué significa: La capacidad está bien, la fragmentación es moderada. Si frag sube y el rendimiento se degrada, el comportamiento de escrituras aleatorias puede empeorar.

Decisión: Si frag es alta y la latencia sube, considera cambios de carga de trabajo, reducir snapshots, añadir vdevs (con cuidado) o migrar VMs calientes a un pool más fresco.

Task 17: Check LVM-Thin discard effectiveness via thin usage trends

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize Data% Meta%
  data  3.00t 78.34 62.11

Qué significa: La limpieza de snapshots o eliminaciones en invitados debería reducir Data% si discard funciona y los bloques se desmapean. Si Data% solo sube, discard no está pasando (o la carga es realmente append-only).

Decisión: Si discard está roto, arregla la cadena (fstrim en invitado, virtio-scsi, discard=on, soporte subyacente). Si la carga es append-only, deja de esperar que los thin pools “se encojan solos”.

Task 18: Check Proxmox backup load correlation

cr0x@server:~$ systemctl list-timers --all | egrep 'vzdump|pbs|backup'
Tue 2026-02-04 02:30:00 UTC  12min left Tue 2026-02-04 01:30:02 UTC  47min ago vzdump.timer

Qué significa: Un job de backup está programado cerca de la ventana de la que se queja el rendimiento. Los backups pueden disparar actividad de snapshot y lecturas intensivas.

Decisión: Escalona backups, aplica controles de ancho de banda/ionice o mueve el almacenamiento de backups a spindles/NVMe separados para que el I/O de usuario no compita con el de backup.

Tres mini-historias corporativas desde las trincheras del almacenamiento

1) Incidente provocado por una suposición equivocada: “thin significa que no podemos quedarnos sin espacio”

Una empresa mediana consolidó un montón de hosts VMware envejecidos en Proxmox. Eligieron LVM-Thin porque era familiar, ligero y parecía rápido en pruebas tempranas. Alguien hizo una diapositiva que decía “la provisión delgada mejora la utilización”. Cierto. Alguien más oyó “la provisión delgada evita problemas de capacidad”. No es cierto.

Sobreaprovisionaron almacenamiento porque el entorno antiguo tenía mucho espacio libre dentro de filesystems invitados. Semanas después, ocurrió un pico rutinario: actualizaciones de Windows, rotación de logs que salió mal en un par de VMs Linux y un desarrollador ejecutando un job de CI que cacheaba artefactos agresivamente. El thin pool llegó al límite mientras todos dormían.

Los síntomas fueron confusos: un par de VMs se congelaron y luego más empezaron a fallar por timeouts. Las aplicaciones reportaron errores de filesystem. La gente culpó a la red. Alguien reinició una VM, lo que empeoró las cosas porque el reinicio desencadenó replays de journal y escrituras extra. El hypervisor no “cayó”, simplemente no podía satisfacer escrituras de forma fiable.

La causa raíz no fue que LVM fuera “malo”. Fue una asunción operativa: trataron el thin como capacidad elástica en lugar de capacidad prestada. La solución fue aburrida: alarmas en uso de datos y metadata, una política estricta de sobrecommit máximo y reportes programados para que la capacidad fuera conversación semanal en lugar de sorpresa.

Después, conservaron LVM-Thin. También dejaron de permitir crear snapshots sin una caducidad. El incidente no fue un referéndum sobre la tecnología. Fue un referéndum sobre el pensamiento deseoso.

2) Optimización que salió mal: “sync=disabled hizo que las gráficas se vieran geniales”

Otra organización ejecutaba bases de datos en Proxmox con mirrors ZFS locales. Su rendimiento inicial era aceptable pero no espectacular. Un ingeniero bienintencionado leyó un hilo en un foro sobre escrituras síncronas en ZFS y decidió “arreglarlo”. Puso sync=disabled en el dataset que albergaba los ZVOLs de la BD.

Los benchmarks mejoraron dramáticamente. La latencia de la aplicación también. El ingeniero se dio una vuelta de celebración y escribió un post interno corto: “el defecto de ZFS es lento; desactiva sync.” Nadie lo desafió porque los números estaban bonitos y los tickets se calmaron.

Meses después tuvieron un evento de energía. No un apagado limpio; el tipo que sucede cuando la infraestructura del edificio toma una decisión distinta a la estimación del UPS. Tras el reinicio, algunas bases de datos arrancaron con corrupción. No todas. Lo suficiente para crear una semana de miseria forense, pruebas de restauración y conversaciones incómodas.

La parte dura fue el postmortem: la “optimización” no causó la falla de energía, pero eliminó los rieles de seguridad que habrían contenido el daño. El equipo tuvo que reaprender que los cambios de rendimiento a menudo cambian las semánticas de durabilidad. Eso no es sintonía, es reescribir el contrato.

La solución fue volver a activar sync, añadir hardware apropiado para escrituras síncronas durables (y validarlo), y volver a ejecutar pruebas específicas de carga. El rendimiento quedó en un lugar sano. Las gráficas eran menos sexys. Los datos eran menos inflamables.

3) Práctica aburrida pero correcta que salvó el día: presupuestos de capacidad y latencia

Una empresa grande ejecutaba cargas mixtas: file servers, apps web, un par de bases de datos y un mar de VMs “pequeñas pero importantes”. Usaban ZFS en la mayoría de nodos y LVM-Thin en algunos donde existían limitaciones de hardware. La diferencia no fue la tecnología. Fue la práctica.

Trataron el almacenamiento como un presupuesto con umbrales. Los pools ZFS tenían un límite suave (no cruzar ~80% para pools calientes sin revisión). Los thin pools tenían alertas en datos y metadata con runbooks claros. Las snapshots tenían TTLs. Los backups se escalonaban. La replicación tenía ventanas de tiempo. Nada de esto era emocionante.

Entonces un proveedor lanzó una mala actualización que provocó que una aplicación registrara agresivamente. Una VM comenzó a escribir a una velocidad que normalmente crearía un incidente. No ocurrió, porque los paneles del equipo señalaron rápidamente latencia creciente y tasas de escritura inusuales. Controlaron la I/O de la VM y revertieron la actualización. Otros workloads apenas notaron nada.

La lección: los controles “aburridos” no previenen todos los problemas, pero convierten los cortes en eventos contenidos. La pila tecnológica se vuelve resistente no porque sea mágica, sino porque puedes ver el problema temprano y reaccionar con intención.

Errores comunes: síntoma → causa raíz → arreglo

1) Síntoma: VMs se congelan aleatoriamente por segundos bajo carga

Causa raíz: Presión de memoria del host causa swapping, o ARC de ZFS compite con la RAM de las VMs; la latencia de almacenamiento es un efecto secundario.

Arreglo: Comprueba free -h y uso de swap; capa ARC si es necesario; asegura margen de memoria reservado para el host; reduce el caos del ballooning.

2) Síntoma: fio muestra throughput enorme, pero las bases de datos se quejan de latencia

Causa raíz: El benchmark usó I/O bufferizado o no incluyó patrones síncronos/flush; no midió latencia de cola.

Arreglo: Reprueba con patrones síncronos y mide p95/p99. Si estás en ZFS, evalúa SLOG con PLP; si estás en LVM, verifica modos de caché y política de caché de la unidad.

3) Síntoma: Uso del thin pool sube indefinidamente incluso después de borrar datos en invitados

Causa raíz: Discard/TRIM no funciona de extremo a extremo, o los filesystems invitados no triman.

Arreglo: Activa discard=on para discos de VM, asegura virtio-scsi, ejecuta fstrim en invitados, verifica soporte de discard subyacente (lsblk -D).

4) Síntoma: Tras semanas, VMs con muchas snapshots se vuelven lentas

Causa raíz: Proliferación de snapshots causando fragmentación y sobrecarga de metadata (ZFS o LVM-Thin), horarios de backup solapándose con picos.

Arreglo: Impone TTLs de snapshots, reduce retención de snapshots a nivel hypervisor, mueve backups fuera de horas pico, evita cadenas largas de snapshots.

5) Síntoma: ZFS “se siente lento” en escrituras, especialmente con muchas escrituras síncronas pequeñas

Causa raíz: No hay SLOG para workloads síncronos, o el SLOG es el dispositivo equivocado (alta latencia, sin PLP), o la carga está limitada por paridad en RAIDZ.

Arreglo: Añade SLOG apropiado solo si las escrituras síncronas dominan; prefiere mirrors para IOPS de VM; no pongas sync=disabled como solución casual.

6) Síntoma: Metadata de LVM-Thin sube rápido en porcentaje

Causa raíz: Muchas snapshots, workloads con alta rotación, asignaciones de bloques pequeñas; LV de metadata demasiado pequeño.

Arreglo: Reduce el número de snapshots, expande el LV de metadata (con cuidado y plan), monitoriza Meta% separadamente de Data%.

7) Síntoma: Un disco parece “arrastrar” todo el host de forma intermitente

Causa raíz: Resets/timeouts de dispositivo, throttling térmico o problemas de firmware (especialmente en NVMe). La pila de almacenamiento recibe la culpa.

Arreglo: Revisa dmesg, logs SMART/NVMe, actualizaciones de firmware; reemplaza hardware sospechoso. Deja de tunear software para compensar hardware inestable.

8) Síntoma: Pool ZFS está sano pero el rendimiento es inconsistente

Causa raíz: Fragmentación, cargas mixtas o contención de CPU por compresión/checksums; también posible mismatch de ashift desde la creación inicial del pool.

Arreglo: Verifica configuraciones del pool, mide CPU, revisa propiedades de datasets; considera migrar workloads calientes o añadir vdevs en lugar de “tuneos misteriosos”.

Listas de verificación / plan paso a paso

Elegir ZFS vs LVM-Thin (lista práctica de decisión)

1. Define la mezcla de cargas. ¿Bases de datos? ¿Muchas VMs pequeñas? ¿Mayormente servicio de ficheros secuencial? No adivines—muestra I/O real si puedes.
2. Decide qué fallos puedes tolerar. ¿La corrupción silenciosa es inaceptable? ¿La sorpresa de capacidad es inaceptable? Elige qué riesgo gestionas mejor.
3. Elige tu layout de vdev o política de thin pool.
   • ZFS para IOPS de VM: mirrors suelen ser la jugada.
   • LVM-Thin: decide ratio máximo de overcommit y haz que se cumpla.
4. Planifica el ciclo de vida de snapshots. TTLs, ventanas de backup y quién puede crear snapshots.
5. Planifica el monitoreo antes del despliegue. No después del primer incidente.

Plan de despliegue ZFS (valores por defecto seguros que envejecen bien)

1. Crea pools con alineación correcta de sectores (ashift) desde el día uno. Cambiarlo después es doloroso.
2. Prefiere mirrors para workloads intensivos en VMs a menos que tengas un diseño muy específico orientado a capacidad y aceptes la compensación de rendimiento.
3. Activa compression=lz4 y atime=off para datasets de VM.
4. Capa ARC si el host está limitado de memoria. Deja margen para las VMs.
5. Añade SLOG solo cuando la latencia síncrona esté probada como cuello de botella, y solo con dispositivos adecuados.
6. Establece TTL de snapshots y horarios de replicación/backup que eviten horas pico.

Plan de despliegue LVM-Thin (haz que thin sea suficientemente seguro)

1. Dimensiona metadata de thin generosamente. La metadata no es donde quieras ahorrar espacio.
2. Activa monitorización para el thin pool y umbrales de alerta para datos y metadata.
3. Decide: permitir overcommit o no. Si sí, define un techo duro y un proceso de revisión.
4. Asegura que discard funcione de extremo a extremo y programa trims en los invitados cuando corresponda.
5. Mantén bajo el número de snapshots y con tiempo límite. Trata las snapshots como herramientas, no colecciones.
6. Ejecuta backups con throttling y evita solaparlos con ventanas I/O críticas para el negocio.

Lista de respuesta a incidentes (cuando el almacenamiento está “lento”)

1. Confirma que no es CPU/memoria/red primero.
2. Encuentra el dispositivo más ocupado y la VM más ocupada.
3. Correlaciona con backups/snapshots/ventanas de replicación.
4. Revisa estadísticas de pool/vdev de ZFS o uso y metadata de LVM thin.
5. Revisa logs del kernel por resets de dispositivo.
6. Haz un cambio a la vez; mide; revierte si es incorrecto.

FAQ

1) ¿Debo usar ZFS o LVM-Thin en un homelab Proxmox?

Si quieres seguridad y facilidad para aprender snapshots/replicación, usa ZFS. Si tienes restricciones de RAM y quieres sobrecarga mínima, LVM-Thin puede estar bien—solo monitoriza el uso de thin como un adulto.

2) ¿ZFS es “más lento” que LVM-Thin?

A veces, en patrones específicos. ZFS hace checksums, copy-on-write y semánticas transaccionales; eso cuesta algo. Pero ZFS también puede ser más rápido en la vida real gracias a compresión y caché. La pregunta correcta es: ¿cuál entrega menor latencia de cola para tu carga bajo presión de snapshots/backups?

3) ¿Puedo arreglar la latencia de escritura de ZFS poniendo sync=disabled?

Puedes hacer que los benchmarks se vean mejor y la durabilidad peor. Si tu carga emite escrituras síncronas por correctness, desactivar sync cambia el contrato. Arregla la latencia síncrona con hardware apropiado (o con la configuración de la carga) y mide de nuevo.

4) ¿LVM-Thin me protege contra bit rot?

No, no de extremo a extremo como ZFS. Puedes mitigar con buen hardware, RAID con lecturas de mantenimiento y backups, pero LVM-Thin en sí no hace checksums de bloques de usuario como ZFS.

5) ¿Necesito un SLOG para ZFS en Proxmox?

Solo si las escrituras síncronas son un cuello de botella probado. Muchas cargas de VMs no están dominadas por sync. Si añades un SLOG, usa un dispositivo de baja latencia con protección frente a pérdida de energía; de lo contrario puedes empeorar las cosas o hacerlas menos seguras.

6) ¿Por qué empeoró el rendimiento después de meses aunque el hardware no cambió?

Snapshots, fragmentación, llenado del pool y deriva de la carga. Los sistemas de almacenamiento envejecen. Mide fragmentación (ZFS), conteo de snapshots, uso de metadata thin (LVM) y si los backups cambiaron a ventanas pico.

7) ¿RAIDZ está bien para almacenamiento de VMs en ZFS?

PUEDE estarlo, pero no es lo que elegiría por defecto para cargas mixtas de VMs donde la latencia importa. Los mirrors suelen ser mejores para I/O aleatorio. RAIDZ tiene más sentido cuando la eficiencia de capacidad es clave y la carga es más secuencial o tolerante.

8) ¿Qué formato de disco de VM debería usar con cada backend?

En ZFS, los discos respaldados por ZVOLs raw son comunes y rinden bien. En LVM-Thin, volúmenes lógicos raw son típicos. qcow2 añade funciones pero puede añadir sobrecarga y complejidad; úsalo cuando necesites sus características, no por costumbre.

9) ¿Qué tan lleno es “demasiado lleno” para ZFS y LVM-Thin?

Para pools ZFS calientes, cruzar ~80–85% es donde el riesgo de rendimiento sube y la flexibilidad operativa cae. Para LVM-Thin, el peligro es llegar al 100% de datos o metadata; fija alertas mucho antes y guarda un colchón para picos y snapshots.

10) ¿Cuál es la forma más rápida de demostrar si es el backend de almacenamiento o una VM mala?

Usa iostat -xz para encontrar el dispositivo caliente, luego mapea PIDs de QEMU a IDs de VM y busca correlación con backups/snapshots y actividad dentro del invitado. Un infractor es común.

Siguientes pasos que puedes hacer esta semana

1. Deja de confiar en un solo benchmark. Añade una prueba de I/O mixta que reporte latencia p95/p99, y ejecútala dentro de una VM, no solo en el host.
2. Implementa la Guía de diagnóstico rápido como runbook. Pon los comandos exactos que tu equipo debe ejecutar en la plantilla de tickets.
3. Si usas LVM-Thin: configura alertas en Data% y Meta%, confirma la monitorización y prueba que discard funcione de extremo a extremo.
4. Si usas ZFS: comprueba el dimensionamiento de ARC vs RAM del host, verifica que el layout de vdevs coincida con la carga de VMs y valida el comportamiento de escrituras síncronas antes de que alguien “tunee” algo.
5. Pon las snapshots con correa. TTLs, responsabilidad de propietario y ventanas de backup que no coincidan con picos de carga.
6. Haz un simulacro de fallo controlado. Llena un thin pool de prueba. Arranca un disco en un mirror ZFS de prueba. Practica la recuperación mientras todos están despiertos.

Elige ZFS o LVM-Thin, pero no lo elijas porque alguien publicó una bonita gráfica de fio. Elígelo porque entiendes qué optimiza, qué se niega a comprometer y exactamente cómo te castigará cuando te vuelvas perezoso.