El apagón no empezó con un estruendo. Empezó con un correo de “copia de seguridad completada” y un datastore que se volvió un 3% más lento cada día hasta colapsar.
Cuando ejecutas máquinas virtuales con cargas reales, el almacenamiento es donde el optimismo va a morir—en silencio, a las 2 a.m., después del tercer “eliminar instantánea” que se queda atascado.
Esta es una comparación de grado productivo: ZFS en Proxmox frente a VMFS en ESXi. No son características para diapositivas: modos de fallo, precipicios de rendimiento, comportamiento de instantáneas,
y cómo recuperas realmente cuando alguien borró lo equivocado con seguridad.
Tomar la decisión como un operador
Si quieres una versión corta: ZFS es un sistema de archivos + gestor de volúmenes con opiniones. VMFS es un sistema de archivos en clúster diseñado para alojar archivos de VM de forma segura en almacenamiento compartido.
Resuelven problemas distintos, y la trampa es fingir que son intercambiables.
Elige ZFS en Proxmox cuando
- Tú posees los discos (NVMe/SATA/SAS locales) y quieres integridad de extremo a extremo, scrubs y herramientas de recuperación predecibles.
- Valoras las instantáneas como primitiva de primera clase que puedes replicar (
zfs send/receive) y razonar sobre ellas. - Puedes aplicar disciplina de almacenamiento: recordsize/volblocksize, ashift correcto y evitar trampas de amplificación de escritura.
- Quieres transparencia para depuración: ZFS te dice lo que sabe. También te dice lo que sospecha.
Elige VMFS en ESXi cuando
- Estás en almacenamiento SAN compartido (FC/iSCSI/NVMe-oF) y necesitas acceso en clúster con bloqueo de VMware, multipathing e integración con el ecosistema del proveedor.
- Estás estandarizado operacionalmente en vSphere: flujos de trabajo de vCenter, DRS, HA y playbooks de soporte del proveedor.
- Quieres comportamiento predecible aprobado por el proveedor incluso cuando es menos transparente. A veces lo aburrido es el objetivo.
No elijas por ideología (“open source” vs “enterprise”). Elige según lo que puedas mantener sano a escala con tu equipo,
tu rotación de on-call y la realidad de tu hardware.
Una cita para tener en el bolsillo durante debates de almacenamiento: la idea de Werner Vogels (parafraseada) de que “todo falla, todo el tiempo”
y los sistemas deben diseñarse alrededor de eso.
Broma #1: Si alguien dice “el almacenamiento es fácil”, o nunca se ha tenido que autodespertar por una alerta, o está a punto de hacerlo.
Hechos interesantes y contexto histórico
- ZFS debutó en Sun a mediados de los 2000 como un sistema de archivos combinado y gestor de volúmenes, con la intención de reemplazar capas de RAID + LVM + sistema de archivos por una pila coherente.
- Copy-on-write (CoW) no era nuevo, pero ZFS lo hizo operacionalmente útil a escala: instantáneas, sumas de comprobación y autocuración estaban integradas en lugar de añadidas por separado.
- VMFS se diseñó para almacenamiento de virtualización en clúster, enfocándose en permitir de forma segura que múltiples hosts ESXi accedieran al mismo datastore concurrentemente.
- El mecanismo de instantáneas de VMware no es “una copia de seguridad” por diseño; es una cadena delta para tareas operativas de corta duración—sin embargo, la gente sigue tratándolo como una máquina del tiempo.
- ZFS verifica con checksums cada bloque (datos y metadatos), permitiendo la detección de corrupción silenciosa que RAID tradicional podría devolver como “exitoso”.
- VMFS ha evolucionado desde reservas SCSI más costosas hasta bloqueos más finos (ATS y mecanismos relacionados), reduciendo la contención en LUNs compartidos.
- El ARC de ZFS cambió cómo se piensa la caché: es adaptativo, consciente de metadatos y puede dominar la planificación de memoria para hipervisores si lo permites.
- Ambas pilas pueden sufrir “fallos exitosamente lentos”: sin errores duros, solo latencia creciente hasta que las aplicaciones agotan el tiempo y los humanos entran en pánico.
Instantáneas: lo que crees que pasa vs lo que pasa
Instantáneas ZFS en Proxmox: semántica limpia, bordes afilados
Las instantáneas de ZFS son baratas de crear y costosas de mantener—específicamente, costosas en el sentido de que retienen bloques antiguos e impiden que el espacio libre se reutilice.
La instantánea en sí es metadatos; el coste en espacio es la divergencia tras la instantánea. Operacionalmente, esto es excelente: obtienes vistas puntuales rápidas,
semántica de reversión predecible y replicación eficiente vía zfs send.
En Proxmox, normalmente almacenarás discos de VM ya sea como ZVOLs (dispositivos de bloque respaldados por ZFS) o como archivos (qcow2/raw) dentro de datasets.
Las instantáneas de ZVOL encajan bien con las instantáneas de disco de VM porque el hipervisor obtiene una instantánea consistente del dispositivo de bloque. No es magia, sin embargo:
la consistencia a nivel de aplicación aún requiere cooperación del huésped (qemu-guest-agent, congelar sistema de archivos, ganchos conscientes de base de datos).
Los bordes afilados son familiares:
- Proliferación de instantáneas: instantáneas cada 15 minutos retenidas durante meses convertirán “espacio libre” en “ficción contable”. ZFS no eliminará bloques aún referenciados.
- Fragmentación: churn de instantáneas intenso puede fragmentar asignaciones; las lecturas se vuelven más lentas y los resilver se vuelven más feos.
- Riesgo de reversión: revertir un dataset o ZVOL es un instrumento contundente. Es rápido. También es definitivo para todo lo escrito después de la instantánea.
Instantáneas VMFS en ESXi: cadenas delta y drama de consolidación
Las instantáneas de ESXi crean VMDKs delta. Las escrituras van al delta; la base permanece mayormente sin cambios. Esto es conveniente operativamente para ventanas de mantenimiento cortas.
El coste aparece más tarde: cuanto más tiempo exista la cadena de instantáneas y más cambios tenga, más se convierte el I/O en una búsqueda a través de múltiples archivos.
El modo de fallo más común no es “existe una instantánea”. Es “la eliminación de la instantánea dispara consolidación, que dispara una copia/merge grande,
que dispara latencia, que dispara timeouts de aplicación, que hace que la gente empeore la situación.”
Si nunca has visto una consolidación atascada mientras el datastore está al 92% de uso, no has experimentado plenamente ese género especial de miedo
donde cada clic es una decisión moral.
Guía de instantáneas para vivir con ellas
- ZFS: mantén calendarios de instantáneas ajustados y retenciones intencionales. Replica fuera del host. Monitoriza
usedbysnapshotsexplícitamente. - ESXi/VMFS: trata las instantáneas como andamios operativos temporales. Si necesitas puntos de restauración, usa un producto de backup que entienda VMware.
- Ambos: mide el coste de las instantáneas por latencia, no por ideología.
Rendimiento: latencia, IOPS y el “depende” que puedes medir
Qué significa realmente el rendimiento para hipervisores
Los hipervisores no “necesitan IOPS”. Necesitan latencia baja y predecible. Una VM con base de datos no le importa que tu almacenamiento haga 400k IOPS a profundidad de cola 128
si la latencia del 99.º percentil de escrituras sube a 40 ms durante merges de instantáneas. Tus usuarios sentirán los picos, no tus benchmarks.
Características de rendimiento de ZFS
El rendimiento de ZFS está dominado por algunos elementos:
- Recordsize / volblocksize: si no coinciden con la carga de trabajo fabricas amplificación de escritura.
- Dimensionamiento del ARC: privar de caché de página al host y privar a las VMs son formas diferentes de tener un mal día.
- Comportamiento de SLOG: solo importa para escrituras síncronas; no es una “caché de escritura” como la gente desearía.
- Compresión: puede ser una ganancia gratis en CPUs modernas, pero depende de la carga y puede aumentar la contención de CPU en nodos ocupados.
Para cargas VM, ZVOLs con volblocksize sensato (a menudo 8K–16K según la carga) y compression=lz4 son puntos de partida comunes.
Pero no actúes por imitación. Mide con tus huéspedes reales.
Características de rendimiento de VMFS
El rendimiento de VMFS está moldeado por el almacenamiento subyacente y la ruta: caché del array, diseño RAID, saturación del controlador, ajustes iSCSI/FC, firmware de HBA,
política de multipathing, profundidades de cola y contención entre hosts.
VMFS en sí rara vez es el cuello de botella a menos que:
- estés haciendo operaciones intensas de metadatos en un datastore estresado,
- estés sufriendo contención por bloqueo, thrashing de rutas o eventos APD/PDL,
- estés ejecutando cadenas profundas de instantáneas y forzando lecturas aleatorias a través de deltas.
Dónde la gente se equivoca comparando rendimiento
Comparan ZFS local en NVMe con VMFS en un array de gama media por iSCSI y concluyen que ZFS es “más rápido”. No es de extrañar.
O comparan VMFS en un SAN FC afinado con ZFS en un espejo SATA único y concluyen que VMware es “más rápido”. Tampoco es de extrañar.
Compara arquitecturas honestamente: local vs compartido, nivel de redundancia, caché del controlador, red y dominios de fallo.
Broma #2: Hacer benchmarks de almacenamiento es como probar un paracaídas leyendo el manual—reconfortante hasta el salto.
Recuperación: las partes que tocarás durante un incidente
Recuperación en ZFS: herramientas deterministas, realidad implacable
ZFS brilla cuando algo se corrompe en silencio. Las checksums lo detectan. Los espejos/RAIDZ pueden autocorregirse. Los scrubs encuentran problemas antes que los usuarios.
Cuando falla un disco, el resilver es generalmente más seguro que un rebuild RAID clásico porque ZFS sabe qué bloques están asignados y son relevantes.
Pero ZFS exige que respetes la física:
- La capacidad importa: a ZFS no le gusta funcionar caliente. A medida que los pools se llenan, la fragmentación y el rendimiento de escritura se degradan. Los tiempos de resilver crecen.
- Ashift equivocado es para siempre: elige un alineamiento de sector incorrecto y pagarás en latencia durante la vida del pool.
- Los rebuilds RAIDZ no son mágicos: siguen leyendo mucho y estresan los discos restantes.
Recuperación en VMFS: caminos operativos y límites del proveedor
La recuperación en VMFS a menudo depende del comportamiento del array, la fibra SAN y del manejo de VMware de fallos de ruta.
Si una LUN desaparece brevemente, puedes obtener escenarios APD (All Paths Down) o PDL (Permanent Device Loss).
Tu recuperación trata menos de “reparar un sistema de archivos” y más de estabilizar el acceso y asegurar la consistencia de los metadatos.
VMFS también obliga a disciplina sobre instantáneas y espacio libre. A menudo puedes recuperarte de “ups, borré una VM” si tienes copias de seguridad,
o si el array proporciona sus propias instantáneas. Pero VMFS no te salvará de fantasías de aprovisionamiento delgado ni de un array que mienta sobre bloques libres.
La pregunta de recuperación que importa
Pregunta: “Cuando las cosas se ponen raras, ¿tengo un procedimiento determinista que un ingeniero on-call pueda ejecutar sin tener al proveedor de almacenamiento al teléfono?”
ZFS suele puntuar mejor en almacenamiento local. VMFS suele puntuar mejor cuando ya tienes una práctica SAN madura y un modelo de soporte.
Problemas reales que golpean a personas experimentadas
Problemas de ZFS en Proxmox
- ARC vs VMs: ZFS tomará memoria con gusto. Si no lo limitas, vas a dejar a los huéspedes sin memoria y culparás a una “lentitud aleatoria”.
- zvol vs qcow2: qcow2 trae su propio CoW y sobrecarga de metadatos; apilar CoW sobre CoW puede ser aceptable o desastroso según el comportamiento de sync/trim.
- Malentendidos sobre SLOG: un SLOG rápido ayuda escrituras sincronas, pero no puede arreglar un pool que no puede sostener tu carga de escritura.
- Expectativas de TRIM/discard: aprovisionamiento delgado y discard requieren alineación entre el SO invitado, el hipervisor y la configuración de ZFS.
- Pensamiento “las instantáneas son gratis”: no lo son. Son facturación diferida.
Problemas de VMFS en ESXi
- Cadenas de instantáneas: instantáneas de larga duración destruyen la predictibilidad. La consolidación puede arruinar el rendimiento en el peor momento.
- Aprovisionamiento delgado en varias capas: VMDK thin sobre LUN thin sobre array thin es un truco de confianza. Eventualmente, alguien se queda sin espacio real.
- Suposiciones sobre la política de multipath: “round robin” no siempre está configurado o no siempre es apropiado por defecto. El desequilibrio de rutas puede parecer latencia aleatoria.
- Profundidad de cola y límites de HBA: un host puede intimidar al datastore mientras otros sufren. Parece “VMware está lento” pero es contención.
- Manejo de APD/PDL: si no lo has ensayado, la primera vez será durante un incidente, lo cual es un entorno de ensayo terrible.
El problema compartido: monitorizar lo equivocado
Ambos mundos fallan cuando monitorizas promedios e ignoras la latencia en la cola, tendencias de espacio libre y trabajo de mantenimiento en segundo plano.
El almacenamiento no necesita tu atención hasta que realmente la necesita. Tu trabajo es notarlo antes.
Guion de diagnóstico rápido
Cuando el almacenamiento está “lento”, no adivines. Triasea rápido, aísla la capa y solo entonces empieza a ajustar.
Este es el orden que más reduce el tiempo hasta la verdad en producción.
Primero: confirma que es latencia de almacenamiento, no CPU steal o presión de memoria
- En el hipervisor: comprueba CPU ready/steal, swapping del host, ballooning y carga general.
- En la VM: comprueba si la aplicación está bloqueada por I/O (iowait) o atascada por locks.
Segundo: identifica lectura vs escritura, sync vs async, aleatorio vs secuencial
- Picos de latencia de escritura durante ventanas de backup suelen significar instantánea/replicación/consolidación.
- Picos de latencia de lectura con escrituras estables suelen indicar fragmentación, fallos de caché o problemas de ruta.
- Dolor por escrituras síncronas sugiere SLOG (ZFS) o problemas de caché/BBU del array (SAN).
Tercero: encuentra el punto de contención
- ZFS: ¿pool ocupado? ¿un vdev saturado? ¿ARC thrashing? ¿scrub/resilver en curso?
- VMFS: ¿contención en datastore? ¿thrashing de rutas? ¿saturación de puerto del array? ¿límites de profundidad de cola?
Cuarto: revisa espacio libre y deuda por instantáneas
- ZFS: pool al 80%+ con muchas instantáneas es un precipicio de rendimiento predecible.
- VMFS: datastore casi lleno hace que las operaciones de instantánea sean arriesgadas y puede disparar dolor de consolidación de emergencia.
Quinto: elige una acción segura
- Reduce la carga de escritura, pausa backups no críticos, reprograma scrubs, evacua VMs calientes.
- No “ajustes todo” durante el incidente. Cambia una cosa que puedas revertir.
Tareas prácticas: comandos, salida y decisiones
Estas son tareas reales que ejecutarás cuando algo se sienta mal. Cada una incluye: el comando, qué significa la salida y la decisión que tomas.
Los comandos están escritos para un host Proxmox/ZFS o un host ESXi según corresponda.
1) ZFS: comprobar salud del pool y contadores de errores
cr0x@server:~$ zpool status -v
pool: rpool
state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all supported features.
scan: scrub repaired 0B in 00:12:41 with 0 errors on Sun Dec 22 03:00:18 2025
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0_2 ONLINE 0 0 0
errors: No known data errors
Significado: ONLINE con cero errores READ/WRITE/CKSUM es lo que quieres. Scrub completado con 0 errores es confianza silenciosa.
“Some supported features…” suele no ser un incidente; es una elección de mantenimiento.
Decisión: Si ves CKSUM no cero, asume problemas de hardware/ruta hasta demostrar lo contrario; planifica reemplazo de disco y ejecuta un scrub después.
Si un scrub está en curso durante el pico, considera reprogramarlo pero no lo canceles a la ligera.
2) ZFS: identificar quién consume espacio (especialmente instantáneas)
cr0x@server:~$ zfs list -o name,used,avail,refer,usedbysnapshots,mountpoint -r rpool
NAME USED AVAIL REFER USEDBYSNAPSHOTS MOUNTPOINT
rpool 820G 120G 192K 0B /rpool
rpool/data 810G 120G 192K 0B /rpool/data
rpool/data/vm-100-disk-0 220G 120G 180G 40G -
rpool/data/vm-101-disk-0 310G 120G 140G 170G -
Significado: usedbysnapshots muestra bloques retenidos por instantáneas. Esos 170G son “espacio que no puedes reclamar” hasta eliminar instantáneas.
Decisión: Si la holgura del pool es ajustada, elimina instantáneas intencionalmente (más antiguas primero), o replica y luego poda. No esperes hasta 95% de uso.
3) ZFS: listar instantáneas y detectar deriva de retención
cr0x@server:~$ zfs list -t snapshot -o name,used,creation -s creation | tail -n 6
rpool/data/vm-101-disk-0@auto-2025-12-27_0200 1.2G Sat Dec 27 02:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0300 1.1G Sat Dec 27 03:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0400 1.3G Sat Dec 27 04:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0500 1.4G Sat Dec 27 05:00 2025
rpool/data/vm-101-disk-0@weekly-2025-11-24 32G Mon Nov 24 00:00 2025
rpool/data/vm-101-disk-0@monthly-2025-09-01 58G Mon Sep 1 00:00 2025
Significado: las instantáneas horarias están bien hasta que las semanales/mensuales se quedan para siempre y acumulan divergencia.
Decisión: aplica retenciones; si se requieren instantáneas mensuales, asegura que el tamaño del pool lo contemple o replica fuera del nodo y poda localmente.
4) ZFS: confirmar recordsize/volblocksize y compresión para almacenamiento de VM
cr0x@server:~$ zfs get -o name,property,value -H recordsize,compression rpool/data
rpool/data recordsize 128K
rpool/data compression lz4
cr0x@server:~$ zfs get -o name,property,value -H volblocksize,compression rpool/data/vm-101-disk-0
rpool/data/vm-101-disk-0 volblocksize 8K
rpool/data/vm-101-disk-0 compression lz4
Significado: los datasets tienen recordsize (I/O de archivo). Los ZVOLs tienen volblocksize (I/O de bloque). Una VM con DB intensiva en un volblocksize de 128K puede sufrir.
Decisión: si ves amplificación de escritura patológica, crea nuevos ZVOLs con volblocksize apropiado y migra discos. No puedes cambiar volblocksize en el lugar.
5) ZFS: comprobar latencia de I/O del pool y qué vdev está sufriendo
cr0x@server:~$ zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
rpool 820G 120G 210 980 12.3M 55.1M
mirror-0 820G 120G 210 980 12.3M 55.1M
nvme-SAMSUNG_MZVLB1T0 - - 102 480 6.1M 27.5M
nvme-SAMSUNG_MZVLB1T0_2 - - 108 500 6.2M 27.6M
-------------------------- ----- ----- ----- ----- ----- -----
Significado: esto muestra la distribución por vdev. Si un lado de un mirror hace todas las lecturas o escrituras, podrías tener un problema de dispositivo o de ruta.
Decisión: si el ancho de banda/ops está desequilibrado o aparecen errores, revisa SMART y cableado/backplane; prepárate para reemplazar el dispositivo sospechoso.
6) ZFS: ver si un scrub/resilver te está robando recursos
cr0x@server:~$ zpool status
pool: rpool
state: ONLINE
scan: scrub in progress since Sun Dec 28 10:03:11 2025
312G scanned at 1.10G/s, 84G issued at 302M/s, 820G total
0B repaired, 10.24% done, 00:41:12 to go
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0_2 ONLINE 0 0 0
Significado: el scrub es intensivo en I/O. En algunos pools está bien; en otros es un evento de rendimiento.
Decisión: si los picos de latencia coinciden con scrubs, reprograma scrubs a horas valle; considera ajustar zfs_vdev_scrub_max_active solo tras medir el impacto.
7) Proxmox: comprobar qué tipo de almacenamiento respalda un disco de VM (zvol vs qcow2)
cr0x@server:~$ qm config 101 | egrep 'scsi|virtio|ide|sata'
scsi0: local-zfs:vm-101-disk-0,size=200G
scsi1: local-lvm:vm-101-disk-1,size=50G
Significado: local-zfs indica un volumen respaldado por ZFS (comúnmente un ZVOL). Esto impacta la mecánica de instantáneas y los ajustes de rendimiento.
Decisión: si una VM es sensible al rendimiento, prefiere un disco sencillo basado en bloque (ZVOL o raw en almacenamiento rápido) sobre formatos CoW apilados a menos que necesites funciones de qcow2.
8) Linux/Proxmox: comprobar si ZFS está dejando al host sin memoria
cr0x@server:~$ arcstat 1 3
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
10:21:11 812 44 5 9 20 10 23 25 57 62.1G 64.0G
10:21:12 790 51 6 11 21 9 18 31 61 62.2G 64.0G
10:21:13 805 47 5 10 21 8 17 29 62 62.2G 64.0G
Significado: el tamaño del ARC cerca de c indica que ZFS está usando lo que se le permite. Si el host está haciendo swap mientras ARC es enorme, los huéspedes sufren.
Decisión: limita ARC (zfs_arc_max) si el host necesita memoria para las VMs; no “dejes que ZFS se coma la RAM” en un hipervisor ocupado a menos que hayas demostrado que es seguro.
9) ZFS: comprobar comportamiento de escrituras sync y si estás forzando sync
cr0x@server:~$ zfs get -o name,property,value -H sync,logbias rpool/data/vm-101-disk-0
rpool/data/vm-101-disk-0 sync standard
rpool/data/vm-101-disk-0 logbias latency
Significado: sync=standard respeta las peticiones de la aplicación. sync=disabled es una palanca de pérdida de datos disfrazada de ajuste de rendimiento.
Decisión: deja sync intacto a menos que entiendas los requisitos de durabilidad de tu carga. Si necesitas rendimiento sync, invierte en un SLOG correcto y protección frente a pérdida de energía.
10) ESXi: listar datastores y espacio libre (comprobación de seguridad de instantáneas)
cr0x@server:~$ esxcli storage filesystem list
Mount Point Volume Name UUID Mounted Type Size Free
------------------------------------------------- ----------- ----------------------------------- ------- ---- ---------- ----------
/vmfs/volumes/DS_VMFS01 DS_VMFS01 64c1d7f1-0b12c9a0-3b7d-001b21aabbcc true VMFS-6 10.00T 1.12T
/vmfs/volumes/BOOTBANK1 BOOTBANK1 5f2a0f13-5caa1122-0000-000000000000 true vfat 3.99G 2.10G
Significado: 1.12T libres puede ser suficiente—o peligrosamente bajo—dependiendo de la consolidación de instantáneas y el aprovisionamiento delgado subyacente.
Decisión: si el espacio libre está descendiendo y tienes instantáneas, deja de añadir riesgo: consolida, evacua VMs, amplía el datastore o elimina con un plan seguro.
11) ESXi: identificar el estado de instantáneas (desde el host)
cr0x@server:~$ vim-cmd vmsvc/getallvms | head
Vmid Name File Guest OS Version Annotation
12 app-portal-01 [DS_VMFS01] app-portal-01/app-portal-01.vmx ubuntu64Guest vmx-19
cr0x@server:~$ vim-cmd vmsvc/snapshot.get 12
GetSnapshot: Snapshot tree:
|-ROOT
+-Snapshot Name : pre-upgrade
Snapshot Id : 1
Snapshot Created On : 12/27/2025 01:12:44
Snapshot State : poweredOn
Significado: existe una instantánea y no es nueva. Eso es riesgo. La antigüedad importa porque el crecimiento delta y la complejidad de la cadena se acumulan.
Decisión: planifica consolidación en baja carga. Si la VM escribe mucho, espera un merge ruidoso; planifica capacidad y holgura de rendimiento.
12) ESXi: detectar problemas de pathing y rutas muertas
cr0x@server:~$ esxcli storage core path list | egrep -A3 'Runtime Name|State:|Preferred'
Runtime Name: vmhba64:C0:T2:L10
State: active
Preferred: true
Runtime Name: vmhba64:C0:T3:L10
State: dead
Preferred: false
Significado: una ruta muerta puede crear latencia intermitente y thrash de failover según la política de multipathing y el comportamiento del array.
Decisión: arregla la tela de conexiones antes de ajustar nada. Reemplaza ópticas/cables, revisa puertos de switch, valida zoning y confirma salud del target del array.
13) ESXi: comprobar latencia del dispositivo desde la vista del hipervisor
cr0x@server:~$ esxtop -b -n 1 | head -n 12
# esxtop batch mode
# Time: 2025-12-28 10:35:11
# ...
Significado: en la práctica usarás esxtop interactivo y mirarás métricas de disco como DAVG (dispositivo), KAVG (kernel) y GAVG (huésped).
DAVG alto sugiere array/almacenamiento; KAVG alto sugiere colas en ESXi; GAVG alto es lo que perciben las VMs.
Decisión: si DAVG es alto en varios hosts, habla con el equipo del array. Si KAVG es alto en un host, revisa profundidad de cola, HBA y VMs “vecinas ruidosas”.
14) Proxmox: medir presión de I/O y latencia a nivel de nodo rápidamente
cr0x@server:~$ iostat -x 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
12.01 0.00 4.20 8.55 0.00 75.24
Device r/s w/s rMB/s wMB/s await r_await w_await svctm %util
nvme0n1 210.0 980.0 12.3 55.1 6.20 3.10 6.90 0.40 48.0
Significado: await te da una imagen aproximada de latencia. %util alta con await en aumento sugiere saturación.
Decisión: si estás saturando un dispositivo/vdev único, mueve carga o rediseña (más vdevs, discos más rápidos, separar cargas). No intentes “sysctl” para salir de la física.
Tres microhistorias del mundo corporativo
Microhistoria #1: un incidente causado por una suposición errónea
Una empresa mediana migró un clúster desde un array envejecido a NVMe locales en Proxmox con mirrors ZFS. El rendimiento mejoró al instante.
El equipo celebró activando instantáneas frecuentes “porque las instantáneas son baratas”.
Asumieron que “baratas” significaba “gratis”. Tras un par de meses, el pool estaba alrededor del 88% asignado, pero la monitorización seguía pareciendo bien
porque el espacio libre bruto nunca llegó a cero y nada lanzaba errores. Luego la ventana de backup nocturna empezó a llevar más tiempo,
y el helpdesk empezó a etiquetar tickets con “lentitud”.
Un fin de semana, una gran actualización de aplicación escribió muchos datos nuevos. La latencia se disparó. El pool cruzó a la zona donde la fragmentación y los mapas de espacio
hicieron las asignaciones caras. Las VMs no se cayeron; simplemente se volvieron no responsivas. Ese es el peor tipo de fallo porque parece un problema de red,
de aplicación, de DNS—cualquier cosa menos “almacenamiento”.
El ingeniero on-call borró un puñado de instantáneas viejas, esperando alivio inmediato. Ayudó, pero no de forma rápida; la eliminación aún tenía que liberar metadatos,
y el pool ya estaba estresado. La solución real fue dolorosa pero directa: implementar retención con límites estrictos, replicar fuera del host
y mantener holgura operacional. También aprendieron a graficar “used by snapshots” por dataset.
Suposición errónea: “Si la interfaz me deja crearlas para siempre, debe ser seguro.” Las UIs de almacenamiento son educadas. La física no lo es.
Microhistoria #2: una optimización que salió mal
Otra organización ejecutaba ESXi con VMFS en un array iSCSI compartido. Intentaban reducir latencia en una VM SQL ocupada.
Alguien leyó que “el aprovisionamiento delgado es lento”, así que convirtieron varios VMDKs grandes a eager-zeroed thick durante horas de trabajo.
La conversión en sí generó una enorme corriente de escrituras. La caché de escritura del array la manejó hasta que dejó de hacerlo.
La red iSCSI empezó a mostrar microexplosiones. Otros hosts experimentaron picos de latencia intermitentes, que dispararon timeouts de aplicación,
que dispararon reintentos, lo que aumentó la carga. Bucle de retroalimentación clásico.
El equipo vio que el datastore VMFS estaba “bien” y que el array estaba “saludable”. Esa es la trampa: los indicadores de salud a menudo significan “no muerto”, no “rápido”.
vCenter mostró alarmas de latencia de almacenamiento crecientes. El equipo de base de datos vio deadlocks y culpó a la aplicación.
Tras estabilizar pausando las conversiones y evacuando algunas VMs ruidosas, hicieron el análisis aburrido:
contadores de ruta, profundidades de cola y gráficos de rendimiento del array. El array no estaba roto; estaba saturado por un trabajo masivo de escritura bienintencionado.
La optimización no estaba mal. La sincronización sí lo estuvo.
Optimización que salió mal: “Hagamos transformaciones pesadas de almacenamiento en el datastore de producción durante el pico.” A veces el trabajo de rendimiento solo mueve el dolor.
Microhistoria #3: la práctica aburrida pero correcta que salvó el día
Una firma de servicios financieros ejecutaba Proxmox con ZFS para cargas de sucursales y ESXi con VMFS para cargas centrales. Dos pilas diferentes, un hábito compartido:
ensayaban la recuperación y mantenían runbooks que realmente se podían ejecutar.
Un nodo Proxmox perdió un disco en un mirror. Sin drama: sonó la alerta, el ingeniero comprobó zpool status, reemplazó la unidad, observó el progreso del resilver
y validó un scrub más tarde. Las VMs siguieron funcionando. Nadie escribió un postmortem porque nada se incendió.
Semanas después, un bug de firmware de un switch SAN causó breves flaps de ruta. Los hosts ESXi vieron rutas muertas intermitentes.
Como el equipo había ensayado su playbook APD/PDL, no persiguieron fantasmas en el SO invitado.
Verificaron rutas, estabilizaron la tela y solo entonces empezaron a evacuar VMs del datastore más afectado.
La práctica salvadora no fue una característica elegante. Fueron scrubs rutinarios, restauraciones probadas y una cultura de “demuéstralo que funciona” en lugar de “supón que funciona.”
Lo aburrido ganó. De nuevo.
Errores comunes: síntoma → causa raíz → solución
1) El pool ZFS parece sano, pero las VMs se vuelven más lentas cada semana
Síntoma: no hay errores de disco, pero la latencia de lectura sube y el I/O aleatorio empeora.
Causa raíz: churn de instantáneas y alta ocupación del pool causando fragmentación; aumentan los misses del ARC; pool demasiado lleno.
Solución: reduce la retención de instantáneas, mantén más espacio libre (apunta a holgura significativa), considera añadir vdevs (no solo discos más grandes) y mide antes/después con percentiles de latencia.
2) “Espacio libre” en ZFS parece bien, pero no puedes recuperar espacio tras borrar datos
Síntoma: datos borrados en la VM, pero el uso del dataset sigue alto; el pool sigue ajustado.
Causa raíz: las instantáneas retienen bloques antiguos; el discard del huésped no pasa; TRIM no está configurado/funcionando de extremo a extremo.
Solución: comprueba usedbysnapshots, poda instantáneas, habilita discard donde corresponda y valida con pruebas controladas—no con esperanza.
3) VM ESXi se congela durante eliminación de instantánea
Síntoma: la eliminación de la instantánea se queda estancada, la latencia del datastore se dispara, la VM queda no responsiva.
Causa raíz: la consolidación/merge es pesado; datastore demasiado lleno; array subyacente saturado; cadena de instantáneas profunda.
Solución: asegura espacio libre en el datastore, realiza consolidación en horas valle, reduce I/O competitivo (pausa backups) y evita instantáneas de larga duración como política.
4) El datastore VMFS reporta mucho espacio, luego de repente llega al comportamiento “sin espacio”
Síntoma: las escrituras fallan, las VMs se pausan, suenan alarmas del array, pero el datastore no parecía “lleno” la semana pasada.
Causa raíz: aprovisionamiento delgado en múltiples capas; la capacidad real del array se agotó mientras VMFS aún pensaba que había espacio.
Solución: monitoriza la capacidad real del array, establece límites conservadores de overcommit y aplica alarmas en vCenter y en el lado del almacenamiento.
5) Escritas sync en ZFS son dolorosamente lentas tras “ajustar”
Síntoma: commits de base de datos se arrastran; latencia se dispara; alguien dice “añade un SLOG” y no ayuda.
Causa raíz: carga de trabajo intensiva en sync y el pool no lo sostiene; el dispositivo SLOG es lento o carece de protección frente a pérdida de energía; o sync fue forzado sin querer.
Solución: valida comportamiento sync, usa SSD/NVMe empresariales con PLP para SLOG y arregla el rendimiento del pool subyacente (más vdevs, mejor medio).
6) Picos de latencia en ESXi solo en un host
Síntoma: un host ve latencia alta mientras otros están bien en el mismo datastore.
Causa raíz: mala configuración de pathing, diferencias en profundidad de cola, mismatch de firmware o un host saturando su HBA.
Solución: compara configuración de multipath entre hosts, revisa rutas muertas, alinea versiones de firmware/controlador y detecta vecinos ruidosos con esxtop.
Listas de verificación / plan paso a paso
Lista de planificación: elegir entre almacenamiento local ZFS y almacenamiento compartido VMFS
- Define dominios de fallo: ¿quieres que la falla de un host arrastre el almacenamiento (local), o necesitas continuidad de almacenamiento compartido?
- Define objetivos de recuperación: RPO/RTO para restaurar VMs y si puedes restaurar sin intervención del proveedor.
- Inventaría patrones de escritura: bases de datos, logging, colas de mensajes—estos castigan picos de latencia.
- Decide política de instantáneas: instantáneas operativas vs backups; retención; objetivo de replicación; procedimiento de restauración probado.
- Plan de capacidad con holgura: incluye retención de instantáneas, sobrecarga de rebuild/resilver y crecimiento en un “día malo”.
- Plan de monitorización: latencia de cola, tendencia de espacio libre, cuenta/antigüedad de instantáneas, estado de scrub/resilver, salud de rutas.
ZFS en Proxmox: constrúyelo y opéralo en serio
- Elige la topología correcta: mirrors para IOPS/latencia; RAIDZ para capacidad; no finjas que RAIDZ es tan rápido como mirror.
- Configura ashift correctamente al crear el pool: asume sectores 4K (o mayores para algunos SSD). Ashift equivocado es un impuesto de por vida.
- Decide ZVOL vs archivos dataset: por defecto ZVOL para discos de VM salvo que necesites funciones específicas de qcow2.
- Establece valores por defecto sensatos: compression=lz4; atime=off para datasets de VM; volblocksize consistente para nuevos discos de VM según clase de carga.
- Limita ARC si es necesario: los hipervisores necesitan memoria para huéspedes primero, ARC después.
- Programa scrubs: mensual es común; más frecuente para hardware más inestable. Monitoriza cambios en duración.
- Instantánea y replica: instantáneas locales para reversión rápida, instantáneas replicadas para recuperación real.
- Prueba restauraciones: “zfs send succeeded” no es lo mismo que “la VM arrancó”.
VMFS en ESXi: opéralo con seguridad bajo carga real
- Configura bien el multipathing: política consistente entre hosts, alertas de ruta muerta y buena higiene de switches/array.
- Monitoriza la latencia en la capa correcta: conoce patrones DAVG/KAVG/GAVG y qué implican.
- Establece política de instantáneas: instantáneas operativas solo; aplica límites de edad; automatiza reportes.
- Disciplina de capacidad: mantiene holgura en datastores; no juegues el todo a aprovisionamiento thin-on-thin.
- Ensaya escenarios APD/PDL: decide cuándo hacer failover, cuándo evacuar y cuándo dejar de tocar el sistema.
- Backups que entiendan VMware: consistentes a nivel de aplicación cuando sea necesario y pruebas de restauración que incluyan red y arranque.
Preguntas frecuentes
1) ¿Las instantáneas de ZFS son “mejores” que las de ESXi?
Son mejores como primitiva de almacenamiento: semántica consistente, creación barata y replicación vía send/receive. Las instantáneas de ESXi son herramientas operativas que se vuelven pasivos cuando se mantienen demasiado tiempo.
Si quieres puntos de restauración, trata las instantáneas de ESXi como transitorias y usa backups para durabilidad.
2) ¿ZFS reemplaza a los controladores RAID?
En muchos diseños, sí: usa HBAs en modo JBOD y deja que ZFS gestione redundancia e integridad. Pero debes diseñar vdevs correctamente y monitorizarlos.
El RAID por hardware aún puede ser apropiado en ciertos entornos restringidos, pero apilar RAID bajo ZFS a menudo reduce la observabilidad y puede complicar la recuperación.
3) ¿Debería usar qcow2 sobre ZFS en Proxmox?
Solo si necesitas funciones de qcow2 (p. ej., ciertos comportamientos sparse) y has probado el rendimiento. Para la mayoría de discos de VM en ZFS, ZVOLs son más simples y a menudo más rápidos.
CoW sobre CoW puede funcionar, pero también es una forma fácil de crear latencia que vas a diagnosticar mal durante semanas.
4) ¿SLOG es obligatorio para almacenamiento VM en ZFS?
No. SLOG importa para escrituras síncronas. Muchas cargas de VM son mayormente asíncronas. Si tienes bases de datos o NFS con requisitos sync, un buen SLOG puede ayudar.
Un SLOG malo puede perjudicar—o al menos fallar de forma espectacular.
5) ¿Qué tan lleno es “demasiado lleno” para pools ZFS?
No hay un número único, pero el rendimiento y el riesgo de resilver empeoran a medida que llenas el pool. Pasado ~80% deberías actuar como si estuvieras en zona de peligro,
especialmente con instantáneas intensas. Pasado ~90% estás negociando con la entropía.
6) ¿Qué tan lleno es “demasiado lleno” para datastores VMFS?
Si dependes de instantáneas o tienes crecimiento impredecible, “lleno cómodo” es un mito. Mantén holgura para eventos de consolidación y crecimiento delta inesperado.
El umbral exacto depende del tamaño y tasa de cambio de las VMs, pero datastores casi llenos hacen peligrosas las operaciones con instantáneas.
7) ¿Puede ZFS ofrecerme almacenamiento compartido como VMFS?
No directamente de la misma manera. ZFS suele ser local a un host. Puedes construir almacenamiento compartido encima (NFS/iSCSI exportado desde ZFS),
o usar sistemas de archivos en clúster y estrategias de replicación, pero esa es una arquitectura diferente con modos de fallo distintos.
8) ¿Cuál es la forma más limpia de replicar almacenamiento ZFS de Proxmox?
La replicación de instantáneas con zfs send/receive es la primitiva limpia. Proxmox tiene herramientas alrededor, pero la verdad subyacente es:
estás enviando deltas de instantáneas. Valida ancho de banda, alineación de retención y la capacidad de arrancar VMs restauradas.
9) ¿Por qué a veces las consolidaciones de instantáneas en ESXi tardan una eternidad?
Porque la consolidación es una copia/merge grande bajo carga y compite con I/O de producción. Si el delta es enorme, el datastore está ocupado
o el array está cerca de saturación, el merge se arrastra. La “solución” es la prevención: mantén las instantáneas de corta duración.
10) Si mi array tiene instantáneas, ¿me sigue importando las instantáneas VMFS?
Sí. Las instantáneas del array pueden ser excelentes para rollback crash-consistente a nivel de LUN, pero debes entender la coordinación con VMware,
el quiesce y los flujos de restauración. Las instantáneas VMFS no son sustituto; son una herramienta distinta con un radio de impacto distinto.
Próximos pasos
Si ejecutas Proxmox con ZFS: audita la retención de instantáneas, grafica usedbysnapshots, limita ARC si los hosts están ajustados de memoria y verifica que los scrubs se completen según lo programado.
Luego realiza una prueba de restauración que arranque una VM y valide la salud de la aplicación. No “el dataset existe”—la VM realmente funciona.
Si ejecutas ESXi con VMFS: inventaría las instantáneas en la flota, aplica una edad máxima, verifica la holgura de datastores y valida la salud del multipath.
Luego ensaya una consolidación en condiciones controladas para que la primera vez no sea durante un incidente.
Si estás eligiendo entre ellos: deja de tratarlo como una guerra religiosa. Mapea tus dominios de fallo, madurez operacional y requisitos de recuperación.
Elige la pila que puedas mantener aburrida.