Proxmox LVM-thin “out of data space”: liberar espacio sin destruir máquinas virtuales

octubre 7, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 7

¿Te fue útil?

Lo notas cuando las copias de seguridad fallan primero. Luego una VM se congela a mitad de escritura. Después Proxmox empieza a mostrar errores como
thin-pool ... out of data space y de repente tu tranquilo host de virtualización actúa como una maleta hecha por un niño: nada más cabe y todo está por el suelo.

La buena noticia: un thin pool de LVM que alcanza “out of data space” suele poder recuperarse sin borrar las VMs. La mala noticia:
debes actuar con criterio, porque “liberar espacio” en almacenamiento thin provisioned no es lo mismo que borrar archivos.
Vamos a arreglar el pool, no a “limpiar alrededor”.

Qué significa realmente “out of data space” (y qué no significa)

El almacenamiento local-lvm de Proxmox suele ser un thin pool de LVM: un gran volumen lógico (el “thinpool”) desde el que se asignan discos de VM
(LVs thin) según la demanda. Puedes sobreaprovisionar: presentar 10 TB de discos virtuales respaldados por 2 TB de bloques reales,
siempre que los invitados no escriban realmente todo eso.

Cuando el thinpool informa que está “out of data space”, significa que el LV de data del pool (la parte que almacena los bloques reales)
está lleno. Las escrituras a cualquier volumen thin pueden quedar bloqueadas o fallar. Dependiendo de tu configuración, LVM puede pausar el pool para evitar
corrupción, lo que se manifiesta como “todo está colgado” a nivel de VM.

Dos matices críticos que te evitan tomar la peor decisión a las 2 a.m.:

Borrar archivos dentro de una VM no necesariamente libera espacio del thinpool a menos que discard/TRIM esté habilitado y se ejecute.
Sin discard, el host sigue pensando que esos bloques están en uso.
Las instantáneas no son “seguro gratis”. Las snapshots thin pueden crecer dramáticamente si el disco base sigue cambiando.
Las instantáneas son copy-on-write; un flujo sostenido de cambios las convierte en devoradoras silenciosas de espacio.

Si recuerdas una cosa: tu trabajo es determinar si el pool está sin data, sin metadata o ambos, y luego elegir la forma menos arriesgada de reclamar o añadir espacio. El pánico es opcional.

Broma #1: Un thinpool no “se queda sin espacio”, alcanza “utilización completa” justo antes de que tu SLA alcance un nuevo mínimo.

Guía rápida de diagnóstico (primera/segunda/tercera comprobación)

Esta es la secuencia “no te pierdas en los detalles” que uso cuando un host Proxmox me notifica sobre espacio en el thinpool.
El objetivo es localizar el verdadero cuello de botella en menos de cinco minutos.

Primero: confirma qué está lleno (data vs metadata) y si el pool está pausado

Comprueba el uso del thinpool con lvs (Data% y Meta%).
Mira el estado del pool: ¿está activo, solo lectura o suspendido?

Segundo: identifica qué está consumiendo bloques (snapshots, backups, volúmenes huérfanos)

Lista los LVs con tamaños y Data% para encontrar los que más escriben.
Lista las snapshots en Proxmox y en LVM (no siempre cuentan la misma “historia”).
Revisa volúmenes abandonados por VMs borradas o restores fallidos.

Tercero: decide la palanca de emergencia (reclamar vs ampliar vs ambos)

Si puedes añadir capacidad rápidamente: extiende el VG y el thinpool.
Si no puedes: recupera espacio eliminando snapshots y ejecutando discard/trim, luego considera medidas temporales.
Si el factor limitante es metadata: amplia la metadata ahora; es pequeña, rápida y suele ser la verdadera culpable.

Si estás indeciso: ampliar el thinpool (data + metadata) es la opción con menos drama si tienes algún espacio libre en el VG o puedes añadir un disco. Recuperar espacio es más matizado y suele sorprender a la gente.

Hechos y contexto interesantes (por qué se comporta así LVM-thin)

Esto no es trivia por trivia. Cada punto se corresponde con un modo de fallo o una mejor práctica operativa.

Las snapshots de LVM preceden a la provisión thin y eran famosas por caídas de rendimiento. Las snapshots clásicas usaban un volumen COW separado y podían degradarse mucho cuando estaban casi llenas; las snapshots thin mejoraron la mecánica pero no eliminaron
la realidad de que “el espacio crece con el churn”.
La provisión thin es una promesa, no una garantía. Es matemáticamente posible provisionar más capacidad virtual de la que puedes almacenar físicamente; el pool solo se mantiene sano si el crecimiento de escrituras se mantiene bajo control.
Los thin pools tienen dos restricciones: data y metadata. La metadata rastrea los mapeos de bloques virtuales a bloques físicos. Puedes tener mucho espacio de data y aun así morir por agotamiento de metadata.
La presión sobre la metadata aumenta con la fragmentación y las instantáneas. Más mapeos, más eventos copy-on-write y más churn a nivel de bloque incrementan el consumo de metadata.
Discard/TRIM no se volvió operativo de la noche a la mañana. Muchas pilas dejaron discard desactivado por años porque las implementaciones iniciales provocaban problemas de rendimiento o comportamiento inesperado en ciertos almacenamientos.
Los valores por defecto de Proxmox para “local-lvm” están pensados para conveniencia, no para perfección. Es un punto de partida razonable para laboratorios y pequeños clústeres, pero espera tener que monitorizar y ajustar.
El auto-extend del thin pool existe, pero no es una niñera. LVM puede auto-extender un thinpool cuando alcanza un umbral, pero solo si el VG tiene extents libres. Si el VG también está lleno, seguirás chocando contra un muro.
La recuperación de espacio es una negociación entre capas. El sistema invitado debe marcar bloques como libres, el sistema de archivos debe soportar trim, la ruta del disco virtual debe pasar discard, y el thinpool debe aceptarlo.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas reales que puedes ejecutar en un nodo Proxmox. Cada una incluye: el comando, una salida representativa y la
decisión que tomas a partir de ella. No pegues ciegamente. Lee la salida como si fuera un informe diagnóstico—porque lo es.

Task 1: Identify the thinpool and see data% and meta%

cr0x@server:~$ sudo lvs -a -o+seg_monitor,lv_attr,lv_size,data_percent,metadata_percent,pool_lv,origin vg0
  LV                      VG  Attr       LSize   Data%  Meta%  Pool          Origin  Monitor
  root                    vg0 -wi-ao----  96.00g
  swap                    vg0 -wi-ao----   8.00g
  data                    vg0 twi-aotz--   1.60t  99.12  71.43                         monitored
  data_tmeta              vg0 ewi-ao----   8.00g
  data_tdata              vg0 ewi-ao----   1.60t
  vm-101-disk-0           vg0 Vwi-aotz--  80.00g                 data                 monitored
  vm-102-disk-0           vg0 Vwi-aotz-- 200.00g                 data                 monitored

Qué significa: El thinpool LV es vg0/data (Attr empieza con twi-). Data% es 99.12%: estás efectivamente sin espacio.
Meta% es 71.43%: la metadata no es el bloque inmediato, pero va en tendencia.

Decisión: Trátalo como una emergencia. Para cualquier cosa que escriba mucho (backups, restores, tormentas de logs),
deténlas y decide entre reclamar/ampliar ahora. Si Meta% estuviera 95–100%, prioriza extender la metadata primero.

Task 2: Check whether the thinpool is suspended (writes may hang)

cr0x@server:~$ sudo dmsetup status /dev/vg0/data
0 3355443200 thin-pool 0 5118/524288 131072/1048576 - rw no_discard_passdown queue_if_no_space

Qué significa: El pool está en modo rw y configurado en queue_if_no_space. Eso significa que las escrituras pueden encolarse cuando está lleno
en lugar de fallar de inmediato. Eso parece “más seguro” hasta que te das cuenta de que puede bloquear tu carga de trabajo y tu paciencia.

Decisión: Si estás atrapado en una espiral de colas de escritura, debes liberar o añadir espacio. También considera si
queue_if_no_space es el comportamiento que quieres a largo plazo.

Task 3: Quick Proxmox-level view: what storage is full?

cr0x@server:~$ pvesm status
Name      Type     Status           Total        Used       Avail      %
local     dir      active        100789248    22133704    73419180   21.96%
local-lvm lvmthin  active       1753219072  1738919936     14299136   99.18%

Qué significa: local (almacenamiento por directorio) está bien. local-lvm está básicamente lleno. Los discos VM en local-lvm están en riesgo.

Decisión: Enfócate en la remediación LVM-thin, no en borrar cosas aleatorias en /var/lib/vz.

Task 4: Find the worst offenders at the LV level

cr0x@server:~$ sudo lvs -o lv_name,lv_size,lv_attr,data_percent,metadata_percent --sort -lv_size vg0
  LV            LSize   Attr       Data%
  data          1.60t   twi-aotz--  99.12
  vm-102-disk-0 200.00g Vwi-aotz--
  vm-101-disk-0  80.00g Vwi-aotz--
  root           96.00g -wi-ao----
  swap            8.00g -wi-ao----

Qué significa: Los volúmenes thin no muestran Data% aquí (eso es a nivel de pool), pero esto te dice qué VMs tienen discos virtuales grandes.
El tamaño virtual grande no prueba uso físico grande, pero es una buena lista corta de “qué VM probablemente está causando churn”.

Decisión: Correlaciona estas VMs con trabajos recientes de backup, mantenimiento de bases de datos, picos de logs o proliferación de snapshots.

Task 5: Check thin pool detailed report (chunks, transaction id, features)

cr0x@server:~$ sudo lvs -o+chunk_size,lv_health_status,thin_count,discards vg0/data
  LV   VG  Attr       LSize  Pool Origin Data%  Meta%  Chunk  Health  #Thins Discards
  data vg0 twi-aotz-- 1.60t             99.12  71.43  64.00k  ok      12     passdown

Qué significa: El tamaño de chunk es 64K. Los discards están en passdown (buena señal). Health es ok (está lleno, pero no corrupto).

Decisión: Si los discards están deshabilitados aquí, el trimming a nivel host no ayudará mucho. Tendrás que habilitar soporte de discard
y luego ejecutar trims en los invitados o en el host donde aplique.

Task 6: List Proxmox snapshots (the “human” snapshots)

cr0x@server:~$ qm listsnapshot 102
`-> pre-upgrade
    `-> weekly-retain-1
`-> weekly-retain-2

Qué significa: La VM 102 tiene múltiples snapshots. Cada snapshot puede fijar bloques y provocar crecimiento.

Decisión: Si estás sin espacio, elimina snapshots que no necesites—empezando por las más antiguas, tras confirmar
que no forman parte de un flujo activo de backup/replicación.

Task 7: Delete a Proxmox snapshot safely (and what to watch)

cr0x@server:~$ qm delsnapshot 102 weekly-retain-2
Deleting snapshot 'weekly-retain-2'...
TASK OK

Qué significa: Proxmox ha programado la fusión de la snapshot. En almacenamiento thin, las fusiones pueden causar I/O. También pueden
aumentar temporalmente la actividad de escrituras. Eso no es razón para evitar la eliminación; es razón para hacerlo de forma intencional.

Decisión: Si el pool está 99–100% lleno, considera detener a los grandes escritores primero para que la fusión no colisione con el churn de producción.

Task 8: Detect orphaned LVs (the “storage is haunted” problem)

cr0x@server:~$ sudo lvs vg0 | grep -E 'vm-[0-9]+-disk-[0-9]+' | awk '{print $1}'
vm-101-disk-0
vm-102-disk-0
vm-109-disk-0
vm-999-disk-0

cr0x@server:~$ ls /etc/pve/qemu-server/ | sed 's/\.conf$//' | sort | tail -n +1
101
102
109

Qué significa: Existe un LV vm-999-disk-0 pero no hay 999.conf. Ese disco probablemente está huérfano: creado durante un restore fallido,
clonación o manipulación manual.

Decisión: Verifica que realmente no se usa y luego elimínalo para recuperar espacio. No lo borres porque “parece extraño”; bórralo porque has probado que no se usa.

Task 9: Prove a suspected orphan is not referenced by any VM config

cr0x@server:~$ grep -R "vm-999-disk-0" /etc/pve/qemu-server/

cr0x@server:~$ echo $?
1

Qué significa: El código de salida 1 indica “no encontrado”. Eso es evidencia (no prueba) de que no está adjunto.

Decisión: También revisa procesos QEMU en ejecución y mapeos de dispositivos de bloque antes de eliminar.

Task 10: Confirm no running VM has the LV open

cr0x@server:~$ sudo lsof | grep "/dev/vg0/vm-999-disk-0" | head

Qué significa: No hay salida sugiere que nada lo tiene abierto. En un host ocupado, lsof puede ser pesado; úsalo con cuidado.

Decisión: Si no está abierto y no está referenciado, puedes eliminarlo.

Task 11: Remove an orphaned thin LV

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

Qué significa: Eliminaste el mapeo LV. El espacio debería volver al pool inmediatamente (aunque la metadata thin y la contabilidad del kernel pueden retrasarse ligeramente).

Decisión: Vuelve a comprobar Data% y Meta% del thinpool para confirmar el impacto. Si nada cambió, no eliminaste lo correcto—o el pool está bloqueado por metadata.

Task 12: Re-check pool usage after deletions

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize  Data%  Meta%
  data 1.60t  96.44  70.90

Qué significa: Recuperaste ~3% del pool. Eso puede ser suficiente para desbloquear operaciones, pero no es una solución si el crecimiento continúa.

Decisión: Si sigues por encima de ~90% y tienes churn en curso, amplía el pool. Reclamar es un parche temporal a menos que cambies el comportamiento.

Task 13: Check VG free space (can we extend without adding disks?)

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free,vg_free_count
  VG   VSize  VFree   #VFree
  vg0  1.80t  180.00g 46080

Qué significa: Tienes 180G libres en el grupo de volúmenes. Puedes extender el thinpool ahora mismo.

Decisión: Extiende el LV de data del thinpool y considera ampliar la metadata también. Haz ambos; es seguro y barato.

Task 14: Extend thinpool data (online) and then metadata (online)

cr0x@server:~$ sudo lvextend -L +150G /dev/vg0/data
  Size of logical volume vg0/data changed from 1.60 TiB (419430 extents) to 1.75 TiB (458752 extents).
  Logical volume vg0/data successfully resized.

cr0x@server:~$ sudo lvextend -L +2G /dev/vg0/data_tmeta
  Size of logical volume vg0/data_tmeta changed from 8.00 GiB (2048 extents) to 10.00 GiB (2560 extents).
  Logical volume vg0/data_tmeta successfully resized.

Qué significa: Data creció 150G. Metadata creció 2G. La metadata thin es pequeña pero crucial; aumentarla proactivamente suele ser sensato.

Decisión: Vuelve a comprobar Data% y Meta% después. Si Meta% sigue muy alta, puede que necesites más metadata o menos snapshots/churn.

Task 15: Verify the thinpool is now healthy and has headroom

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize  Data%  Meta%
  data 1.75t  88.12  56.41

Qué significa: Has comprado margen de maniobra. 88% sigue siendo “vigilar de cerca” en el mundo thin, pero ya no estás al borde del fallo.

Decisión: Ahora evita recurrencias: habilita discard de extremo a extremo, reduce la retención de snapshots y configura alertas.

Task 16: If there’s no VG free space, add a new disk and extend the VG

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME         SIZE TYPE FSTYPE      MOUNTPOINT
sda        1.8T  disk
├─sda1       1M  part
├─sda2     1G  part ext4         /boot
└─sda3   1.8T  part LVM2_member
  ├─vg0-root  96G lvm  ext4         /
  ├─vg0-swap   8G lvm  swap         [SWAP]
  └─vg0-data 1.75T lvm
sdb        1.0T  disk

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

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

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free
  VG   VSize  VFree
  vg0  2.80t  1.03t

Qué significa: Añadiste capacidad real. Ahora puedes extender el thinpool otra vez.

Decisión: Extiende vg0/data y (opcionalmente) vg0/data_tmeta. Después configura monitorización para no repetir este ritual.

Task 17: Enable weekly TRIM for guests where it makes sense (and confirm)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled)
     Active: active (waiting)

Qué significa: Los invitados que usan systemd pueden descartar bloques liberados periódicamente. Esta es una de las pocas mejoras “configura y olvida”.

Decisión: Asegúrate de que discard esté permitido en la configuración del disco VM y que el sistema de archivos/almacenamiento lo soporte. Si no, solo estarás programando optimismo.

Task 18: Check whether a VM disk is configured to pass discard (Proxmox)

cr0x@server:~$ qm config 102 | grep -E 'scsi|virtio|sata'
scsi0: local-lvm:vm-102-disk-0,discard=on,iothread=1,size=200G

Qué significa: discard=on está habilitado para ese disco. Bien. Sin ello, el TRIM del invitado no llegará al thinpool.

Decisión: Para discos donde quieras reclamación, habilita discard. Para algunos workloads sensibles a latencia, prueba primero—pero la mayoría debería activarlo.

Opciones de recuperación que no destruyen VMs

Cuando te quedas sin data space, tienes tres palancas reales: detener escrituras, reclamar bloques y añadir capacidad. La mejor solución suele ser una combinación.
La solución equivocada es “borrar cosas al azar hasta que el error desaparezca.”

Opción A: Borrar snapshots que no necesitas (la recuperación “real” más rápida)

Si tienes snapshots antiguas, son lo primero que miro. Las snapshots fijan versiones antiguas de bloques y mantienen datos vivos que de otro modo serían reutilizables.
Eliminarlas puede liberar mucho, pero las fusiones generan I/O—así que hazlo con consciencia.

Cuándo hacerlo: el pool está lleno, existen snapshots y puedes tolerar algo de actividad de fusión.
Cuándo evitarlo: la snapshot se usa activamente para rollback en una ventana de cambios planificada (raro).

Opción B: Quitar volúmenes huérfanos y restos de restores fallidos (la jugada “barrer el almacén”)

Proxmox suele ser ordenado, pero los humanos son creativos. Los huérfanos aparecen tras backups fallidos, restores interrumpidos o ediciones manuales de LVM.
Esto puede ser una victoria limpia y de bajo riesgo—si verificas referencias primero.

Opción C: Ampliar el thinpool (lo aburrido, y normalmente lo mejor)

Si el grupo de volúmenes tiene extents libres, ampliar el thinpool es rápido y online. Si no los tiene, añade un disco y extiende el VG.
En términos de incidente, esta es la acción de mayor confianza: reduce la presión inmediatamente.

Opción D: Reclamación desde los invitados con TRIM (bueno, pero no instantáneo)

La reclamación no es magia. El invitado debe emitir discards, el controlador virtual debe pasarlos y el thinpool debe aceptarlos.
Además: el invitado puede no descartar agresivamente salvo que lo indiques (fstrim) o monte con discard continuo (no siempre recomendado).

Opción E: Triage temporal: detener la hemorragia

Si estás en 99–100% y las VMs están atascadas, la acción inmediata es detener trabajos de alta tasa de escritura:
backups, restores, agregación de logs, vacuum/compaction de bases de datos, indexación, churn de artefactos CI.
No estás “arreglando” el problema; estás evitando una falla en cascada mientras creas espacio.

Broma #2: La forma más rápida de recuperar almacenamiento es programar una ventana de mantenimiento; de repente todos recuerdan qué se puede borrar.

Tres micro-historias corporativas desde las trincheras del thinpool

Micro-historia 1: El incidente causado por una suposición equivocada

Una organización mediana gestionaba un clúster Proxmox para servicios internos: Git, runners de CI, algunos servidores de aplicaciones y una base de datos que todos fingían que no era “producción”
porque no era cara al cliente. Vivía en local-lvm, provisionada thin, con discos virtuales generosos. La monitorización observaba el sistema de archivos del host,
no el thinpool. Todo parecía verde—hasta que dejó de estarlo.

La suposición equivocada fue sencilla: “Si el invitado borra archivos, el host recupera espacio.” Sus runners de CI producían artefactos, los subían y luego limpiaban
el workspace. Dentro de la VM, el uso de disco parecía aceptable. En el host, el thinpool subía de uso de todos modos. Nadie lo notó porque no miraban Data%.

Entonces una actualización rutinaria del OS creó nuevos paquetes, los logs rotaron, CI se puso ocupado y el thinpool cruzó la línea. Las escrituras se encolaron. Los runners de CI se quedaron bloqueados. El servicio Git se volvió lento. La base de datos empezó a hacer timeouts porque fsync no terminaba. Parecía “la red está inestable” hasta que alguien realmente chequeó LVM.

La solución no fue heroica: habilitar discard en los discos VM, activar fstrim semanal en los invitados, borrar snapshots obsoletas y ampliar el pool unos cientos de gigas.
El cambio cultural importó más: añadieron monitorización del thinpool y dejaron de tratar local-lvm como “infinito porque es thin”.

Nadie fue despedido. Pero la relación del equipo con las “suposiciones” cambió para siempre. La provisión thin es un contrato con la realidad, y la realidad siempre lee la letra pequeña.

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

Otra compañía quería “copias de seguridad más rápidas”. Estaban creando snapshots de una VM muy activa y ejecutando backups frecuentes. Para reducir el tiempo de backup, aumentaron la frecuencia de snapshots
y guardaron más puntos de restauración. Los gráficos parecían geniales—hasta que el thinpool no lo estuvo.

Las snapshots son baratas al crearlas. Esa es la trampa. La VM era un servidor de aplicaciones con muchos logs y escrituras constantes. Cada snapshot fijaba bloques antiguos; cuantos más snapshots
mantenían, más versiones de bloques calientes vivían simultáneamente. El thinpool se llenó más rápido precisamente porque su “optimización” preservó el churn.

Cuando el thinpool alcanzó el techo, el trabajo de backup que “hacía las cosas más seguras” se convirtió en el desencadenante del downtime. Peor aún: borrar snapshots durante el incidente provocó
una oleada de fusiones exactamente cuando el sistema ya estaba bajo estrés de I/O. Ese trabajo de fusión no era el villano, pero definitivamente no fue calmante.

La solución a largo plazo fue contraintuitiva: menos snapshots, programación de backups más inteligente y separar workloads de alto churn en almacenamiento dimensionado para churn.
También implementaron autoextend con la regla dura de “el VG debe tener espacio libre” y alertas cuando los extents libres bajaban.

El rendimiento mejoró. La fiabilidad mejoró. La queja “los backups son lentos” se transformó en “los backups son aburridos”, que es el mayor elogio que puede recibir operaciones.

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

Un equipo conservador gestionaba Proxmox para plataformas internas. Tenían un estándar simple, casi aburrido: cada backend de almacenamiento tenía alertas en tres niveles (aviso, urgente,
detener-el-mundo), y los thinpools se trataban como bases de datos de producción—planificación de capacidad, no esperanza.

También tenían un hábito que suena a papeleo: después de cada prueba de restore o migración, ejecutaban una “barrida de huérfanos” para verificar que no quedaran volúmenes sueltos.
Era un pequeño script y un recordatorio en calendario. La gente a veces rodaba los ojos.

Una tarde, una prueba de restore falló a mitad por un problema de red. Dejó varios volúmenes thin grandes. Al día siguiente, la barrida de huérfanos los detectó.
Los eliminaron y siguieron con su trabajo. Sin incidente. Sin expansión de emergencia. Sin llamadas a medianoche.

Meses después, otra falla de restore ocurrió durante un periodo ocupado. Pero la misma práctica aburrida se activó. El host nunca llegó al precipicio, porque el equipo no dejó
que basura silenciosa se acumulase.

La lección no fue “sé paranoico”. Fue “sé rutinario”. La mayoría de las caídas no son causadas por bugs exóticos. Son causadas por la acumulación lenta de estado sin dueño.

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

Estos son patrones que veo con frecuencia en entornos reales de Proxmox. Si uno coincide con tu situación, no lo debatas—actúa.

1) Síntoma: el thinpool está lleno, pero el invitado tiene mucho espacio libre

Causa raíz: Discard/TRIM no llega al thinpool, o nunca se emite.
Solución: Habilita discard=on para discos VM; habilita y ejecuta fstrim en los invitados; confirma que los discards del thinpool son passdown.

2) Síntoma: “out of data space” aparece de repente tras habilitar snapshots frecuentes

Causa raíz: Retención de snapshots + alto churn. La copy-on-write fija bloques antiguos; el churn multiplica el espacio consumido.
Solución: Reduce la cantidad/retención de snapshots; programa snapshots en periodos de baja actividad; amplía el pool; considera mover VMs de alto churn a almacenamiento dedicado.

3) Síntoma: data% del pool es moderado, pero las escrituras fallan o el pool parece atascado

Causa raíz: Metadata llena (Meta% cerca de 100%) o riesgo de corrupción de metadata.
Solución: Extiende data_tmeta; reduce snapshots; reduce fragmentación/churn; comprueba salud y considera mantenimiento si sospechas corrupción.

4) Síntoma: borras una VM, pero el uso del thinpool apenas cambia

Causa raíz: Los discos de la VM no estaban realmente en ese thinpool, o existen snapshots/orphans adicionales, o borraste la configuración pero no los discos.
Solución: Revisa qm config y mapeo de almacenamiento; lista LVs; elimina huérfanos; confirma que la eliminación en Proxmox estaba configurada para borrar discos.

5) Síntoma: después de liberar espacio, el pool sigue reportando casi lleno

Causa raíz: Los bloques liberados no fueron descartados; la contabilidad del thinpool se retrasó; o liberaste espacio en el almacenamiento equivocado (directorio vs lvmthin).
Solución: Vuelve a comprobar con pvesm status y lvs; ejecuta trims; confirma discards; asegúrate de operar sobre local-lvm.

6) Síntoma: las fusiones/eliminación de snapshots empeoran el rendimiento durante el incidente

Causa raíz: Borrar snapshots desencadena limpieza/merge de copy-on-write en el peor momento posible.
Solución: Pausa trabajos de escritura intensiva primero; borra snapshots de forma estratégica; añade capacidad para reducir la presión antes de las fusiones si es posible.

Listas de verificación / plan paso a paso

Checklist de emergencia (thinpool al 95–100%)

Detén a los grandes escritores: pausa backups/restores, detén tormentas de logs, retrasa trabajos de mantenimiento de BD.
El objetivo es dejar de acelerar hacia el muro.
Confirma el problema: ejecuta pvesm status y lvs para Data% y Meta%.
Elimina snapshots de bajo valor: empieza por las más antiguas y menos justificadas. Conserva la “una que podrías necesitar” solo si realmente la podrías necesitar.
Elimina huérfanos probados: busca en configs, comprueba handles abiertos y luego lvremove.
Extiende el thinpool si puedes: comprueba vgs; si el VG tiene extents libres, extiende ahora.
Extiende metadata de forma proactiva: especialmente si Meta% > 70% y usas snapshots.
Vuelve a comprobar la salud: confirma que Data% cae a un rango más seguro y que las VMs se recuperan.

Checklist de estabilización (después de detener la hemorragia)

Activa discard de extremo a extremo: ajuste de disco Proxmox discard=on, trims desde el sistema invitado, thinpool con discards passdown.
Define política de snapshots: limita cantidad, edad y alinea con patrones de churn.
Implementa alertas: aviso en 70–80%, urgente en 85–90%, crítico en 95% para Data% y Meta% del thinpool.
Mide el churn: identifica VMs que escriben constantemente; trátalas como multiplicadores de capacidad.
Prueba procesos de restore: los restores fallidos son una fuente principal de volúmenes huérfanos.

Checklist de planificación de capacidad (para que no vuelva)

Define un ratio de sobreaprovisionamiento: elige un número defendible (p.ej., 2:1) y haz que sea cultura.
Rastrea la tasa de crecimiento del thinpool: si Data% crece 1–2% por día, estás en cuenta regresiva.
Mantén espacio libre en el VG: si dependes de autoextend, debes mantener extents libres. Si no, autoextend es solo una bonita idea.
Separa cargas de trabajo: coloca VMs de alto churn en almacenamiento dimensionado para churn, no en el mismo thinpool que la infraestructura “tranquila”.

Prevención: hazlo aburrido, hazlo permanente

La emergencia del thinpool suele no ser un hecho aislado. Es una factura retrasada por comodidad previa: sobreaprovisionar sin monitorizar, snapshots sin disciplina de retención
y invitados que borran datos sin descartarlos.

Monitorización que realmente funcione

Observa el Data% y el Meta% del LV thinpool. No confíes en “espacio libre” dentro de los invitados. No confíes en df -h en el filesystem del host.
Son capas distintas con verdades distintas.

Una regla práctica: alerta con suficiente antelación para poder responder en horario laboral. La idea no es capturar el 99%. La idea es evitar llegar ahí.

Disciplina con snapshots

Las snapshots son deuda operativa con interés compuesto. Consérvalas cuando tengan un propósito: una red de seguridad corta para un cambio arriesgado.
No las guardes “porque el almacenamiento es barato”. En provisión thin, el almacenamiento no es barato; solo está diferido.

Discard: actívalo y luego demuestra que funciona

Activar discard en un disco Proxmox es necesario pero no suficiente. Los invitados necesitan emitir trims. Algunos sistemas de archivos y cargas se benefician de fstrim
periódicos en lugar de mounts con discard continuo. Prueba en tu workload, pero no lo omitas.

Autoextend: buen sirviente, terrible jefe

El autoextend de LVM puede salvarte de sorpresas por crecimiento lento, pero no puede crear espacio de la nada. Solo consume extents libres del VG. Si llevas tu VG a cero,
autoextend se convierte en una falsa sensación de seguridad—como una rueda de repuesto hecha de cartón.

Una cita para mantener la honestidad

Parafraseando una idea de John Allspaw: la fiabilidad viene de cómo se comporta tu sistema bajo estrés, no de desear que el estrés no ocurra.

Preguntas frecuentes

1) ¿Puedo arreglar “out of data space” sin reiniciar el host Proxmox?

Normalmente sí. Extender el thinpool y borrar snapshots/huérfanos son operaciones típicamente online. Los reinicios son para cuando has cavado un agujero más profundo (o por problemas de kernel/controladores),
no para correcciones básicas de capacidad.

2) ¿Cuál es la diferencia entre el espacio “data” y “metadata” del thinpool?

Data son los bloques almacenados realmente para los discos VM. Metadata es la base de datos de mapeo que rastrea dónde vive cada bloque virtual en el pool y cómo se relacionan las snapshots.
Puedes quedarte sin espacio en cualquiera de los dos, y los síntomas pueden parecer similares.

3) ¿Por qué borrar archivos dentro de la VM no libera espacio en el host?

Porque el thinpool solo considera los bloques reutilizables cuando recibe discards. Borrar un archivo marca bloques libres dentro del sistema de archivos, pero sin TRIM/discard,
el almacenamiento subyacente los considera aún asignados.

4) ¿Es seguro habilitar `discard=on` para todas las VMs?

Para la mayoría de cargas generales, sí—y normalmente es la opción correcta con provisión thin. Para algunas cargas sensibles a latencia, prueba primero.
El riesgo mayor es usar thin sin reclamación y luego sorprenderse cuando se llena.

5) Borré snapshots pero Data% apenas se movió. ¿Por qué?

O bien las snapshots no eran el principal consumidor, o el pool está lleno por datos activos todavía referenciados por discos actuales, o en realidad estás limitado por metadata.
Además, “poco movimiento” puede ser significativo si tu pool es de varios terabytes; verifica con lvs y correlaciona con fuentes de churn.

6) ¿Debo añadir más espacio de metadata aunque Meta% no esté alto?

Si usas snapshots intensamente o tienes alto churn, sí—dentro de lo razonable. Ampliar metadata es barato comparado con un incidente donde Meta% llega al 100% y el pool se comporta mal.

7) ¿Puedo reducir un disco VM para recuperar espacio en el thinpool?

Reducir es posible pero raramente la primera opción: requiere reducir el sistema de archivos dentro del invitado (y eso no siempre está soportado), y es operacionalmente arriesgado.
Prefiere la reclamación basada en discard y limpieza de snapshots. Amplía la capacidad si puedes.

8) ¿Cuál es la acción “más segura” inicial cuando el pool está al 99% y las VMs van lentas?

Detén o pausa a los mayores generadores de escritura (backups/restores/tormentas de logs), luego crea espacio borrando snapshots/huérfanos o ampliando el pool.
No empieces “limpieza” dentro de los invitados y esperes que alcance al host. La esperanza no es un driver de almacenamiento.

9) ¿Por qué se llenó tan rápido si los discos VM no son tan grandes?

La plenitud del thinpool depende de bloques escritos físicamente, no del tamaño virtual de los discos. Patrones de alto churn (bases de datos, logs, workspaces CI), más snapshots, pueden multiplicar el uso físico rápidamente.

10) Si extiendo el thinpool, ¿Proxmox lo detectará automáticamente?

En la mayoría de los casos sí; Proxmox lee el estado de LVM y reflejará la nueva capacidad en pvesm status. Si no se actualiza inmediatamente, revisa que hayas extendido el LV correcto
y que la definición de almacenamiento apunte a ese pool.

Conclusión: próximos pasos que debes hacer hoy

Si estás leyendo esto en medio de un incidente, haz tres cosas en orden: confirma si data o metadata están llenos, recupera espacio borrando snapshots y huérfanos probados,
y luego amplía el thinpool (y la metadata) si tienes capacidad para añadir. Eso te saca de la zona de peligro sin destruir VMs.

Luego haz la parte que evita la secuela: habilita discard de extremo a extremo, ejecuta trims, establece retención de snapshots como un adulto y añade monitorización de Data% y Meta% del thinpool.
Haz el almacenamiento aburrido otra vez. Tu yo futuro ya está cansado.