Ubuntu 24.04: pool thin de LVM al 100% — salva tus VMs antes de que sea demasiado tarde

diciembre 14, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 8

¿Te fue útil?

Si tu host Ubuntu 24.04 ejecuta VMs sobre LVM thin y ese thin pool llega al 100%, el modo de fallo no es “un poco lento”. Es “las escrituras se detienen, los invitados quedan bloqueados y tu hipervisor empieza a hacer ruidos desagradables”. No obtienes una cuenta regresiva elegante. Obtienes una alerta y un nudo en el estómago.

Este es el manual que desearía que todo equipo de virtualización tuviera pegado en la puerta del rack: cómo diagnosticar qué está realmente lleno (datos o metadatos), cómo hacer que las VMs vuelvan a respirar sin convertir la recuperación en un segundo incidente, y cómo evitar que la provisión thin se convierta silenciosamente en hielo delgado.

Qué ocurre realmente cuando un thin pool llega al 100%

La provisión thin de LVM es una idea brillante con un filo: te permite prometer más espacio del que físicamente tienes. Eso no es inherentemente malo—los arrays de almacenamiento lo han hecho durante años—pero desplaza el fallo de “tiempo de asignación” a “tiempo de escritura”. Cuando el thin pool se queda sin espacio, no solo fallas al crear un volumen nuevo. Las VMs existentes pueden de repente no poder escribir bloques que nunca habían escrito antes. Eso puede parecer fallos aleatorios de aplicaciones, re-montados de sistemas de archivos, advertencias de corrupción de bases de datos y que los invitados pasen a solo-lectura.

Dos pools distintos pueden arruinarte:

Espacio de datos (el grande): donde viven los bloques de tus LVs thin.
Espacio de metadatos (el pequeño): la tabla de mapeo que dice “este bloque del thin LV mapea a ese bloque físico”.

Cuando el dato está al 100%, las nuevas escrituras que requieren asignación de bloque fallan. Cuando el metadato está al 100%, la contabilidad de asignaciones falla aun cuando todavía tengas espacio de datos. Ambas situaciones pueden detener I/O. Ambas pueden bloquear VMs. Ambas son evitables si tratas la provisión thin como una sustancia controlada.

Una matización más: un thin pool puede volverse malsano incluso antes de llegar al 100% si está muy fragmentado, tiene snapshots descontrolados o sufre ciclos constantes de asignar/liberar. Pero 100% es el titular porque es cuando tu margen se vuelve negativo y empiezas a pagar intereses.

Broma #1: La provisión thin es como el crédito: fantástica hasta que accidentalmente la agotas con “solo un snapshot más”.

Hechos e historia breve: por qué los thin pools se comportan así

Un poco de contexto te ayuda a predecir el comportamiento en lugar de adivinar. Aquí hay hechos concretos y útiles—sin nostalgia, sólo mecánica.

Device-mapper thin provisioning (dm-thin) lleva años en el kernel principal; LVM thin lo usa por debajo. LVM no está “haciendo magia”, está orquestando dispositivos dm-thin.
Los metadatos son un LV separado (a menudo llamado como thinpool_tmeta) porque las tablas de mapeo deben ser consistentes ante fallos y rápidas. Quedarse sin metadatos puede romper la asignación aun cuando los datos parezcan bien.
Los thin pools pueden sobracommitirse por diseño: la suma de los tamaños virtuales de los thin LVs puede exceder el tamaño físico del pool. Ese es el punto—y también la trampa.
El soporte de Discard/TRIM evolucionó lentamente a través de las capas (FS del invitado → disco virtual → host dm-thin). Ahora es viable, pero solo si realmente lo habilitas de extremo a extremo y entiendes el coste de rendimiento.
Los snapshots son baratos al crearlos en provisión thin. Por eso la gente crea demasiados. El coste llega después, a medida que se acumulan bloques divergentes.
Existe autoextend para thin pools (vía monitorización de LVM y perfiles), pero solo ayuda si el VG tiene extensiones libres o puedes añadir PVs rápidamente.
100% no es un límite educado: dm-thin puede cambiar a un modo de error para nuevas asignaciones. Dependiendo de la configuración, los errores de I/O se propagan de forma impredecible a sistemas de archivos y aplicaciones.
Existen herramientas de reparación de metadatos (como thin_check y thin_repair), pero no son herramientas de mantenimiento rutinario. Si las usas mensualmente, tu proceso es el problema.

Hay un principio de confiabilidad que vale la pena tener en el escritorio. Aquí una idea parafraseada de John Allspaw, veterano líder en operaciones y confiabilidad: paráfrasis: los incidentes emergen del trabajo normal en sistemas complejos; culpar no sirve—entender y aprender es la tarea.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando el thin pool llega al 100%, tu trabajo es dejar de adivinar. Sigue un orden estricto. Cada paso responde una pregunta binaria y guía tu siguiente acción.

Primero: ¿es espacio de datos o espacio de metadatos?

Si el dato está lleno: necesitas espacio físico o liberar bloques (TRIM/discard no te salvará rápidamente salvo que ya lo tuvieras en marcha).
Si el metadato está lleno: a menudo puedes extender el LV de metadatos rápidamente (si el VG tiene espacio) y restaurar las asignaciones.

Segundo: ¿las escrituras están fallando ahora mismo?

Revisa los registros del kernel en busca de errores de dm-thin.
Comprueba si los invitados han pasado a solo-lectura o si los servicios están fallando.

Tercero: ¿qué está consumiendo espacio: escrituras reales, snapshots o bloques obsoletos?

Mira el uso por LV.
Identifica patrones de crecimiento de snapshots.
Decide si borrar snapshots, migrar una VM, extender el pool o añadir un PV.

El tiempo importa. Pero “rápido” no significa “creativo”. Significa “hacer las pocas operaciones riesgosas que restauren margen de escritura”.

Tareas prácticas (comandos, salidas y decisiones)

A continuación hay tareas reales que puedes ejecutar en Ubuntu 24.04. Cada una incluye: comando, ejemplo de salida, qué significa y la decisión que tomas. Ejecútalas como root o con sudo. Ajusta nombres de VG/LV a tu entorno.

Tarea 1: Identificar thin pools y su uso

cr0x@server:~$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent,origin,pool_lv --units g
  VG     LV                 Attr       LSize  Data%  Meta%  Origin Pool
  vg0    thinpool           twi-aotz--  900.00g 99.82  12.44        -
  vg0    thinpool_tdata     Twi-aotz--  900.00g
  vg0    thinpool_tmeta     ewi-aotz--    4.00g
  vg0    vm-101-disk-0      Vwi-aotz--   80.00g 62.10
  vg0    vm-102-disk-0      Vwi-aotz--  120.00g 91.34

Significado: twi- indica un thin pool. Data% está peligrosamente alto (99.82%). Metadatos están bien (12.44%).

Decisión: Trata esto como una emergencia de espacio de datos. Necesitas margen inmediato: extender el pool, borrar snapshots o mover una VM fuera del pool.

Tarea 2: Confirmar que el VG tiene espacio libre para extender

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free,vg_free_count --units g
  VG   VSize    VFree   VFreeCount
  vg0  953.00g   0.00g  0

Significado: No hay extensiones libres en el VG. No puedes extender el thin pool sin añadir almacenamiento o mover datos.

Decisión: Planea añadir un nuevo PV (nuevo disco/LUN) o evacuar uno o más thin LVs a otro VG.

Tarea 3: Confirmar si el pool está en modo de problema (mensajes del kernel)

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Dec 29 11:41:20 2025] device-mapper: thin: 253:10: reached low water mark; sending event.
[Mon Dec 29 11:43:02 2025] device-mapper: thin: 253:10: no free space for data block allocation
[Mon Dec 29 11:43:02 2025] blk_update_request: I/O error, dev dm-7, sector 1048576 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Significado: dm-thin está fallando asignaciones. Los invitados verán errores de escritura o bloqueos.

Decisión: Detén escrituras no esenciales. Pausa/detén tareas de backup, trabajos de snapshot, tormentas de logs. Tu prioridad es restaurar margen de escritura.

Tarea 4: Encontrar los thin LVs top por bloques usados

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent,seg_monitor --sort=-data_percent vg0
  LV             LSize   Data%  Meta%  Cpy%Sync Monitor
  vm-102-disk-0  120.00g 91.34
  vm-101-disk-0   80.00g 62.10

Significado: data_percent por thin LV indica cuántos bloques del disco virtual han sido asignados, no el uso del sistema de archivos dentro del invitado.

Decisión: Si una VM está escribiendo descontroladamente, considera apagarla o moverla primero.

Tarea 5: Buscar snapshots que estén consumiendo silenciosamente el pool

cr0x@server:~$ sudo lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent --sort=origin vg0 | sed -n '1,40p'
  LV                    Attr       Origin          LSize   Data%
  thinpool              twi-aotz--                 900.00g
  vm-101-disk-0         Vwi-aotz--                 80.00g  62.10
  vm-101-disk-0-snap    Vri-aotz--  vm-101-disk-0  80.00g  18.43

Significado: Los LVs snapshot (Vri-) acumulan bloques cambiados. Si tu política de snapshots es descuidada, tu pool se llena como una bañera con el desagüe tapado.

Decisión: Identifica snapshots no críticos y bórralos para recuperar bloques (la recuperación no siempre es inmediata; ver notas de TRIM más adelante).

Tarea 6: Comprobar configuraciones del thin pool (autoextend y umbrales)

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,lv_size,segtype,seg_monitor,lv_profile vg0/thinpool
  LV       Attr       LSize    Type  Monitor Profile
  thinpool twi-aotz-- 900.00g thin-pool monitored

Significado: “monitored” significa que lvm2 puede emitir eventos, pero no garantiza crecimiento automático a menos que esté configurado.

Decisión: Después de sobrevivir al incidente, configura un perfil de thin pool con autoextend o añade alertas externas. Durante el incidente, no pierdas tiempo en “ajustes”.

Tarea 7: Verificar el estado del demonio de eventos de LVM (a veces no llegan alertas)

cr0x@server:~$ systemctl status lvm2-lvmpolld lvm2-monitor --no-pager
● lvm2-lvmpolld.service - LVM2 poll daemon
     Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmpolld.service; static)
     Active: active (running)
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
     Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled)
     Active: active (exited)

Significado: Los servicios están presentes. Si nunca recibiste alertas, probablemente no los conectaste (LVM no te paginará mágicamente).

Decisión: Por ahora: concéntrate en liberar espacio. Más tarde: integra con Prometheus/NRPE/lo que uses.

Tarea 8: Añadir un nuevo disco y convertirlo en PV (expansión limpia y rápida)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME        SIZE TYPE MOUNTPOINT
sda         1.0T disk
├─sda1        1G part /boot/efi
├─sda2        2G part /boot
└─sda3      997G part
  ├─vg0-thinpool_tdata 900G lvm
  ├─vg0-thinpool_tmeta   4G lvm
  └─vg0-root            80G lvm /
sdb         500G disk

cr0x@server:~$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

Significado: Tienes un nuevo PV listo para añadirse al VG.

Decisión: Si esto es un hipervisor, prefiere añadir capacidad sobre “limpiezas ingeniosas” cuando el pool ya está al 100%.

Tarea 9: Extender el VG y luego extender el LV de datos del thin pool

cr0x@server:~$ sudo vgextend vg0 /dev/sdb
  Volume group "vg0" successfully extended

cr0x@server:~$ sudo lvextend -L +400G vg0/thinpool
  Size of logical volume vg0/thinpool changed from 900.00 GiB (230400 extents) to 1.29 TiB (332800 extents).
  Logical volume vg0/thinpool successfully resized.

Significado: El pool es más grande. Esto suele ser la forma más limpia de “salir de la cárcel” si puedes añadir almacenamiento rápido.

Decisión: Si Data% estaba ~100% y ves errores de I/O, extender es la solución menos arriesgada. Hazlo primero, luego investiga por qué se llenó.

Tarea 10: Si el problema es metadatos, extiende los metadatos también

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/thinpool
  LV       LSize    Data%  Meta%
  thinpool 1.29t    76.10  99.92

cr0x@server:~$ sudo lvextend --poolmetadatasize +2G vg0/thinpool
  Size of logical volume vg0/thinpool_tmeta changed from 4.00 GiB (1024 extents) to 6.00 GiB (1536 extents).
  Logical volume vg0/thinpool_tmeta successfully resized.

Significado: Los metadatos estaban casi llenos; los aumentaste. Esto puede detener inmediatamente fallos de asignación.

Decisión: Si Meta% está alto (>80% sostenido), trátalo como emergencia. Extender metadatos suele ser rápido y menos problemático que reparar metadatos tras una corrupción.

Tarea 11: Confirmar que el thin pool ya no está anclado al 100%

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/thinpool
  LV       LSize    Data%  Meta%
  thinpool 1.29t    76.09  54.12

Significado: Tienes margen. No “seguro para siempre”, pero suficiente para detener el sangrado activo.

Decisión: Reanuda servicios gradualmente. Mantén las copias de seguridad en pausa hasta estar seguro de la estabilidad y entender el motivo del crecimiento.

Tarea 12: Comprobar si los discards están habilitados para el thin pool

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,discards vg0/thinpool
  LV       Attr       Discards
  thinpool twi-aotz-- passdown

Significado: passdown significa que los discards pueden pasarse al almacenamiento subyacente. Esto es bueno, pero no garantiza que los invitados emitan TRIM, ni que tu capa de hipervisor lo pase.

Decisión: Si confías en que “el espacio libre volverá”, valida TRIM extremo a extremo. De lo contrario, los thin pools solo crecen.

Tarea 13: Comprobar uso del sistema de archivos del host por tormentas de logs (a menudo el disparador)

cr0x@server:~$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root   78G   71G  3.0G  96% /

Significado: Si el root del host está lleno, puedes ver fallos en cascada (journald, libvirt, logs de qemu). Eso puede causar fallos en VMs no relacionados con la capacidad del thin pool—no los confundas.

Decisión: Si el root del host está casi lleno, libéralo también. Un “thin pool arreglado” en un sistema raíz moribundo es solo otro tipo de outage.

Tarea 14: Inspeccionar archivos de disco por VM o LVs desde la capa del hipervisor

cr0x@server:~$ sudo virsh domblklist vm102
 Target   Source
------------------------------------------------
 vda      /dev/vg0/vm-102-disk-0
 vdb      /var/lib/libvirt/images/vm102-seed.img

Significado: Confirma qué LVs están adjuntos. Útil cuando una VM “misteriosamente” escribe a otro disco del que crees.

Decisión: Si una VM ruidosa mapea al thin pool, ahora sabes exactamente qué LV snapshotear/borrar/migrar/limitar.

Tarea 15: Si puedes apagar una VM, reduce su uso de espacio y cuenta de snapshots

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,lv_time,origin vg0 | grep -E 'vm-102|snap'
  vm-102-disk-0        120.00g 91.34  2025-12-28 22:10:14
  vm-102-disk-0-snap   120.00g 44.02  2025-12-29 09:00:11 vm-102-disk-0

Significado: Esto muestra si un snapshot reciente está inflándose. Muchos incidentes de “thin pool de repente lleno” son “trabajo de snapshot fuera de control”.

Decisión: Borra el snapshot si no es necesario para recuperación/cumplimiento—después de confirmar con los responsables. Si es necesario, extiende la capacidad y arregla la política de snapshots luego.

Tarea 16: Borrar un snapshot thin innecesario (con cuidado)

cr0x@server:~$ sudo lvremove -y vg0/vm-102-disk-0-snap
  Logical volume "vm-102-disk-0-snap" successfully removed.

Significado: El snapshot desapareció. Si el espacio es reutilizable inmediatamente depende del comportamiento de discard y de internals de dm-thin, pero la presión de asignación suele bajar.

Decisión: Si eliminaste snapshots y Data% no baja rápido, no entres en pánico. En su lugar, céntrate en detener nuevas escrituras y añadir capacidad.

Tarea 17: Validar el estado de salud del thin pool

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,health_status vg0/thinpool
  LV       Attr       Health
  thinpool twi-aotz-- ok

Significado: “ok” es lo que deseas. Si no está ok, trata el pool como comprometido y prioriza backups/evacuación.

Decisión: Si la salud está degradada, deja de crear snapshots nuevos y programa una ventana de mantenimiento para investigar integridad de metadatos y errores de I/O.

Tácticas de recuperación: elige la opción menos mala

Cuando el thin pool está lleno, estás en un problema de optimización con restricciones: reducir riesgo, restaurar margen de escritura y preservar recuperabilidad. El mejor movimiento depende de lo que tengas disponible: espacio libre en el VG, discos extra, otro host o la posibilidad de apagar VMs.

Opción A (mejor): añadir capacidad, extender el pool y luego investigar

Si puedes adjuntar un disco/LUN nuevo rápido, hazlo. Extender el pool tiene bajo riesgo comparado con cirugía en vivo dentro de los invitados. Además te da margen para la segunda parte: descubrir por qué llegaste a esto.

Operativamente, este es el paso de “detener la hemorragia”. Aún necesitas prevención, pero tus VMs dejan de gritar.

Opción B: evacuar una VM a otro datastore

Si tienes otro VG/backend con espacio, mover una VM pesada puede comprar tiempo. Dependiendo de tu stack (libvirt, Proxmox, scripts personalizados), puedes hacer una migración fría (apagar y copiar) o una migración en vivo (si está soportada). En crisis, la migración fría es aburrida y fiable.

Sé honesto sobre el ancho de banda. Copiar 500G a 1 Gbit/s no es un “arreglo rápido”. Es un plan para mañana salvo que tengas suerte.

Opción C: borrar snapshots (si estás absolutamente seguro)

Los snapshots se sienten como backups hasta que no lo son. Si borras la cadena de snapshots equivocada, puedes eliminar la única vía a una restauración puntual. Pero si los snapshots son claramente innecesarios (snapshots de pruebas, trabajos nocturnos olvidados, plantillas abandonadas), eliminarlos suele ser la palanca de recuperación más rápida.

No borres snapshots a ciegas. Identifica propietarios, verifica ventanas de cambio y confirma si algún flujo de restauración depende de ellos.

Opción D: habilitar/descubrir discards e intentar recuperar espacio

TRIM puede ayudar, pero no es un desfibrilador. Si tus invitados han borrado muchos datos pero no emiten discards, tu thin pool puede estar lleno de bloques muertos. Habilitar discard puede permitir recuperar espacio—pero también puede generar churn de I/O y no necesariamente te llevará del 100% a un nivel seguro en minutos.

Además: no todos los sistemas de archivos invitados emiten TRIM automáticamente; algunos necesitan un fstrim periódico. Las capas de virtualización pueden ignorar discard a menos que esté explícitamente habilitado. Los thin pools pueden pasar discards hacia abajo, pero eso es solo un eslabón de la cadena.

Opción E (último recurso): herramientas de reparación e intervención en metadatos

Si ves corrupción de metadatos o problemas severos de salud del thin pool, puede que necesites comprobaciones offline con thin_check/thin_repair. Esto no es algo para “hacer en producción a las 2pm” a menos que tu alternativa sea pérdida total de datos.

Los flujos de reparación varían por empaquetado de la distro y comportamiento del kernel. El principio seguro es consistente: sacar el pool de servicio, capturar metadatos, validar, reparar si es necesario y restaurar con cuidado.

Broma #2: “Solo corremos thin_repair rapidito” es el equivalente en almacenamiento de “solo voy a reiniciar la base de datos, ¿qué podría salir mal?”.

Tres minihistorias corporativas de la vida real

Mini-historia 1: El incidente causado por una suposición errónea

El equipo heredó un cluster de virtualización que “tenía mucho espacio”. El admin anterior había dimensionado LVs thin generosamente—2–4× lo que los invitados realmente usaban—y a todos les encantó la flexibilidad. Los desarrolladores podían pedir discos más grandes sin papeleo. Nadie percibió el riesgo porque aún no había fallado nada.

La suposición errónea fue sutil: asumieron que porque los invitados estaban al 40–50% a nivel de sistema de archivos, el thin pool debía estar seguro. Miraban df dentro de las VMs, no lvs en el host. También asumieron que las eliminaciones en los invitados devolverían espacio al pool automáticamente.

Luego un workload de CI cambió: las caches de imágenes de contenedor empezaron a escribirse y borrarse intensamente. Los invitados liberaron espacio desde su perspectiva. El thin pool no reclamó esos bloques porque discard no estaba habilitado extremo a extremo.

El pool llegó al 100% en horario laboral. Un subconjunto de VMs se congeló al escribir. Una VM de base de datos pasó a solo-lectura. La respuesta al incidente fue caótica porque el host todavía “tenía espacio” según los invitados. La gente discutía con las gráficas en vez de con los logs del kernel.

La solución fue aburrida: extender el pool, habilitar discard con cuidado y cambiar la monitorización para alertar sobre Data%/Meta% del thin pool, no el uso de filesystem dentro de la VM. La lección quedó porque fue costosa: “espacio libre” es un concepto en capas, y cada capa miente a su manera.

Mini-historia 2: La optimización que salió mal

Un grupo de plataforma decidió reducir ventanas de backup. Sus hipervisores usaban snapshots LVM thin para backups consistentes: snapshot, montar, copiar, borrar. Alguien notó que los snapshots eran baratos de crear y propuso aumentar la frecuencia para mejorar el RPO de sistemas clave.

En papel, era elegante: snapshots frecuentes, copias incrementales más rápidas, menos datos que mover cada vez. En la práctica, el workload era muy escrituro. Los snapshots empezaron a acumular bloques cambiados rápidamente. Las copias “incrementales” no fueron tan incrementales porque los datasets calientes cambiaban por todos lados.

La optimización rebotó de forma clásica: el sistema se volvió más complejo y menos predecible. Data% del thin pool subió lentamente, luego en picada. Tenían alertas al 95%, pero la pendiente era tan empinada que alcanzaron 100% entre comprobaciones, justo cuando varias VMs grandes estaban haciendo actualizaciones de aplicaciones.

Borraron snapshots para recuperar espacio y descubrieron un efecto de segundo orden: los trabajos de backup reintentaron, recrearon snapshots y llenaron el pool de nuevo. El problema no era “los snapshots son malos”. Era “la concurrencia ilimitada de snapshots es mala”.

La remediación final fue política: limitar cantidad de snapshots por VM, serializar operaciones de snapshot y definir un ratio máximo de overcommit thin. El equipo también separó pools: uno para workloads volátiles, otro para bases de datos estables. No porque sea sofisticado, sino porque el radio de impacto existe.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una aplicación financiera corría en un pequeño conjunto de VMs. El equipo que la gestionaba no era glamoroso, pero era disciplinado. Tenían una rutina semanal: revisar uso del thin pool, validar backups, probar una restauración y repasar cualquier deriva de snapshots.

También practicaban una regla: cada hipervisor tenía un procedimiento documentado de “añadir capacidad” con almacenamiento preaprobado. Cuando un pool se acercaba al umbral de advertencia, no debatían si era “real”. Añadían capacidad y luego investigaban las tendencias de consumo una vez resuelto el riesgo inmediato.

En un cierre de trimestre, el workload se disparó. Aumentaron los logs, se generaron archivos intermedios y un job por lotes duplicó temporalmente el volumen de escritura. Data% del thin pool subió rápido. Su monitorización alertó en un umbral conservador y el on-call siguió el playbook sin improvisar.

Adjuntaron un LUN nuevo, extendieron el VG y el thin pool, y mantuvieron el negocio en marcha. No hubo momento de héroe, solo una tarea rutinaria ejecutada bajo presión. La revisión post-mortem fue corta porque el sistema se comportó según lo diseñado.

Ese equipo no “evitó incidentes”. Redujeron la probabilidad de que un incidente de capacidad se convierta en pérdida de datos. En producción, eso es lo que parece la competencia.

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

Estos no son teóricos. Son las formas en que los thin pools castigan el exceso de confianza.

1) Síntoma: VMs se congelan o pasan a solo-lectura, pero CPU/RAM del host parecen bien

Causa raíz: dm-thin no puede asignar nuevos bloques (dato lleno) o no puede actualizar mapeos (metadato lleno). Las escrituras se detienen o fallan.

Solución: Comprueba lvs Data%/Meta% y dmesg. Restaura margen extendiendo el pool o borrando snapshots; extiende metadatos si Meta% está alto.

2) Síntoma: Los invitados muestran mucho espacio libre, pero el thin pool está lleno

Causa raíz: La provisión thin rastrea bloques asignados, no el espacio libre del invitado. Los archivos eliminados no devuelven bloques a menos que los discards fluyan.

Solución: Habilita discard extremo a extremo y programa fstrim en invitados donde corresponda. No confíes en esto como solución de emergencia cuando ya estás al 100%; añade capacidad primero.

3) Síntoma: Meta% del thin pool sube más rápido de lo esperado

Causa raíz: Alto churn: muchas escrituras pequeñas, muchos snapshots o ciclos rápidos de crear/borrar incrementan la complejidad de mapeo.

Solución: Extiende el LV de metadatos proactivamente. Reduce cantidad y vida de snapshots. Considera pools separados para workloads con mucho churn.

4) Síntoma: Extiendo el pool pero Data% sigue alto

Causa raíz: Extendiste muy poco, o los workloads consumieron inmediatamente el espacio nuevo. A veces extendiste el LV equivocado (confusión tmeta/tdata).

Solución: Revisa otra vez lvs -a y confirma que el tamaño del pool cambió. Throttlea/para temporalmente a los mayores consumidores mientras recuperas margen.

5) Síntoma: Borrar un snapshot no “libera espacio” rápidamente

Causa raíz: La reclamación depende de cómo se gestionan los bloques y si los discards están fluyendo. Además, otros escritores pueden estar consumiendo espacio al mismo tiempo.

Solución: Mide de nuevo después de detener trabajos de alta escritura. No uses “borré un snapshot” como único plan—combínalo con añadir margen.

6) Síntoma: Nunca recibiste una alerta; el pool llegó al 100% en silencio

Causa raíz: No hay monitorización de Data%/Meta% del thin pool, o las alertas estaban demasiado altas o con intervalos largos.

Solución: Alerta en múltiples umbrales (por ejemplo, 70/80/90/95) y en la tasa de cambio. Trata a los thin pools como instrumentos de vuelo, no como un dashboard casual.

Prevención: monitorización, política y decisiones de diseño

El objetivo no es “nunca llenar un thin pool”. El objetivo es “no llenar un thin pool inesperadamente”. Quieres tiempo para decidir con calma, no una decisión desesperada.

Define una política de overcommit thin (sí, una política)

La provisión thin sin límite de overcommit es simplemente apostar con mejor UX. Decide tu tolerancia al riesgo:

Para workloads mixtos: mantén la suma virtual por debajo de ~150–200% del físico, dependiendo del churn y tu tiempo de respuesta.
Para CI/build/test volátiles: asume que el crecimiento es real; haz menos overcommit o aisla esas VMs.
Para bases de datos: o no usarlas en thin, o mantener margen físico generoso y límites estrictos de snapshots.

Alerta tanto en Data% como en Meta% (y en la pendiente)

Data% es lo obvio. Meta% es el asesino en el asiento trasero. También alerta sobre la rapidez de cambio de Data%. Un pool al 85% que crece 1% por semana es tarea de presupuesto. Un pool al 85% que crece 1% por hora es un incidente que no notaste aún.

Haz del ciclo de vida de snapshots una prioridad

Los snapshots sin límite son la causa número 1 de autodestrucción de thin pools. Define reglas:

Máximo de snapshots por VM.
Edad máxima (expiración automática).
Serializar trabajos intensivos en snapshots para evitar picos de asignación.

Usa discard/TRIM deliberadamente, no por fe

Discard puede reducir el crecimiento de asignaciones a largo plazo y hacer que los thin pools se comporten más como almacenamiento “real”. También puede añadir sobrecarga. Decide según el workload:

Para pools con SSD/NVMe, discard suele valer la pena.
En algunos SANs o arrays thin-provisioned, el comportamiento del discard varía; pruébalo.
Prefiere trim programado (fstrim.timer) sobre montajes con discard continuo para evitar picos de latencia en ciertos workloads.

Separa pools por radio de impacto

Un único thin pool gigante es eficiente hasta que no lo es. Una VM descontrolada puede consumir los últimos porcentajes y tumbar sistemas no relacionados. Separa pools para:

bases de datos (predecible, de alto valor, baja tolerancia a stalls)
workloads volátiles (CI, scratch, entornos de desarrollador)
staging de backups (si es necesario)

Tener vías preaprobadas para añadir capacidad

En entornos corporativos, la parte más lenta de un incidente de capacidad suele ser la aprobación de compras, no los comandos. Preaprueba un mecanismo de expansión de disco/LUN de emergencia. Hazlo aburrido. Lo aburrido es rápido.

Listas de verificación / plan paso a paso

Lista A: Cuando el thin pool está en 95%+ (pre-incidente)

Ejecuta lvs y confirma si sube Data% o Meta%.
Identifica los mayores consumidores y cualquier pico reciente de snapshots.
Pausa o reprograma trabajos pesados de snapshot/backup hasta restaurar margen.
Si el VG tiene extents libres, extiende el thin pool ahora (no esperes al 100%).
Si el VG está lleno, programa añadir un PV o mover al menos una VM fuera del pool.
Notifica a las partes interesadas: “Estamos en estado de advertencia de capacidad; acción en progreso”.

Lista B: Cuando el thin pool llega al 100% (modo incidente)

Detén la amplificación de escritura: pausa backups, automatización de snapshots, trabajos de logs pesados si es posible.
Confirma uso del thin pool y qué dimensión está llena: lvs Data% vs Meta%.
Revisa los logs del kernel en busca de errores de asignación de dm-thin.
Restaura margen:
- Añade PV y extiende el pool (preferido), o
- Borra snapshots no esenciales (con cuidado), o
- Evacua una VM a otro datastore.
Verifica que el pool esté por debajo de umbrales críticos y que la salud sea ok.
Vuelve a activar los trabajos pausados gradualmente y vigila la pendiente.

Lista C: Después de la recuperación (endurecimiento post-incidente)

Documenta la causa raíz (cambio de workload, job de snapshot, brechas de discard, fallo en planificación de capacidad).
Añade monitorización para Data% y Meta%, con alertas de pendiente.
Aplica políticas de ciclo de vida y límites de snapshots.
Decide la estrategia de discard y pruébala en una ventana de mantenimiento.
Reevalúa la ratio de overcommit thin y separa pools si hace falta.
Ejecuta una prueba de restauración. No porque sea divertido—porque es la única verificación honesta.

Preguntas frecuentes

1) ¿“thin pool 100%” es siempre catastrófico?

No siempre de forma inmediata, pero siempre inaceptable en producción. Algunos workloads pueden seguir funcionando hasta que necesiten nuevas asignaciones de bloque. Tú no controlas cuándo ocurre eso.

2) ¿Qué es peor: datos llenos o metadatos llenos?

Ambos son malos. Metadatos llenos puede ser más sorprendente porque el pool puede tener mucho espacio de datos. La diferencia práctica: los metadatos suelen ser más fáciles de extender rápidamente si tu VG tiene extents libres.

3) Si borro archivos dentro de una VM, ¿por qué no disminuye el thin pool?

Porque el host no puede leer la mente del invitado. El sistema de archivos del invitado marca bloques libres internamente, pero a menos que emita discard/trim y esos discards se pasen a través de la capa de virtualización a dm-thin, el host sigue considerando esos bloques asignados.

4) ¿Puedo confiar en habilitar discard para recuperar desde 100%?

No. Discard es preventivo y de “juego a largo plazo”. Cuando ya estás al 100%, necesitas margen físico inmediato: extender el pool o evacuar datos.

5) ¿Debería apagar VMs cuando el pool está lleno?

Si las VMs están fallando escrituras activamente, apagar a los escritores más ruidosos puede estabilizar mientras extiendes capacidad. Pero prefiere una solución que restaure margen rápido; dejar producción caída mientras discutes no es una estrategia.

6) ¿Cuánto margen debo mantener?

Suficiente para responder con calma. Prácticamente: alerta temprano (70–80%), trata 90% como urgente y evita operar por encima del 95% a menos que disfrutes la adrenalina.

7) ¿Los snapshots thin cuentan contra el pool aunque nunca los use?

Sí, a medida que acumulan bloques cambiados. Crear un snapshot es barato. Mantenerlo durante escrituras intensas no lo es.

8) ¿Autoextend es una buena idea?

Es útil cuando el VG tiene extents libres o tienes una forma automatizada de añadir PVs. No es sustituto de la monitorización y no ayudará cuando el VG ya esté lleno.

9) ¿Por qué crece Meta%—no debería ser estable?

Los metadatos rastrean mapeos. A medida que aumentan las asignaciones y se multiplican los snapshots, la metadata crece. Los workloads con mucho churn pueden inflar metadatos más rápido de lo esperado.

10) ¿Deben las bases de datos vivir en thin provisioning?

Si es necesario, mantén margen estricto y disciplina de snapshots, y monitoriza agresivamente. Muchos equipos prefieren thick provisioning para bases de datos para evitar stalls de asignación impredecibles.

Próximos pasos que realmente reducen el riesgo

Si tu thin pool en Ubuntu 24.04 está en o cerca del 100%, no negocies con la física. Restaura margen primero. Extiende el pool si puedes. Borra snapshots solo cuando estés seguro. Evacúa una VM si es necesario. Luego—y solo entonces—investiga el porqué.

Pasos prácticos para las próximas 24–48 horas:

Añade monitorización sobre Data% y Meta% de lvs, más alarmas por tasa de cambio.
Establece una política de ciclo de vida de snapshots y hazla cumplir técnicamente, no solo socialmente.
Valida discard/TRIM extremo a extremo en una prueba controlada; decide si programar fstrim en invitados.
Define una ratio máxima de overcommit thin y separa workloads volátiles en su propio pool.
Escribe (y ensaya) el runbook de “añadir PV y extender pool” para que el siguiente on-call no lo aprenda a las 3 a.m.

El thin pool no se preocupará de que estuvieras ocupado. Se llenará igual. Tu trabajo es asegurarte de que “lleno” sea un evento planificado, no un incidente.