local-lvm de Proxmox al 100%: encuentra qué llenó tu thin pool y arréglalo

enero 7, 2026 • febrero 3, 2026 • Lectura: 28 min • Views: 17

¿Te fue útil?

Local-lvm al 100% es el equivalente en Proxmox a quedarse sin dirección asistida: todo parece bien hasta el momento en que deja de serlo. Las VMs se quedan congeladas, las copias de seguridad fallan y la interfaz web empieza a lanzar errores como una alarma estresada.

La parte complicada no es que te hayas quedado sin espacio. Es por qué te quedaste sin espacio: aprovisionamiento thin, snapshots, volúmenes huérfanos, amplificación de escritura por copy-on-write, un huésped que nunca hace trim, o metadata que alcanzó el límite antes que los datos. Esto es cómo encuentras qué devoró tu thin pool, lo arreglas sin empeorarlo y evitas que vuelva a ocurrir.

Qué es realmente “local-lvm” (y por qué se llena de forma distinta)

En la mayoría de instalaciones de Proxmox, terminas con dos almacenamientos locales por defecto:

local: un directorio (usualmente /var/lib/vz) para ISOs, plantillas y backups.
local-lvm: un thin pool de LVM usado para discos de VM.

Ese segundo es el problemático cuando llega al 100%. No porque sea malo: LVM-thin es rápido, sencillo y suficiente para muchos clústeres, sino porque es un tipo distinto de “contabilidad de espacio” comparado con un sistema de archivos clásico.

Thin provisioning: espacio prometido vs bloques reales

LVM-thin te permite crear volúmenes virtuales (thin LVs) que reclaman un tamaño —por ejemplo 200G— pero consumen bloques físicos del pool solo a medida que se escriben datos. Eso es aprovisionamiento thin. Facilita la sobreasignación de almacenamiento. También facilita que te sorprendas cuando la realidad te alcanza.

Los snapshots no son gratis, son facturas aplazadas

Los snapshots de LVM-thin son copy-on-write. El snapshot empieza pequeño, pero cada bloque que cambia mientras el snapshot existe debe copiarse y registrarse. Cargas de trabajo con muchas escrituras + “borramos snapshots más tarde” = un thin pool que crece como un archivo de log descontrolado.

Dos límites: datos y metadata

Los thin pools tienen espacio de datos y espacio de metadata. Cualquiera de los dos alcanzando el 100% puede arruinar tu día. La metadata es lo que rastrea qué bloques están asignados a qué volúmenes thin. Si la metadata se llena, las asignaciones pueden fallar aunque haya espacio de datos. Si los datos se llenan, las escrituras fallan aunque la metadata tenga espacio. Fallan de manera diferente y requieren intervenciones distintas.

Idea parafraseada, atribuida a Werner Vogels (CTO de Amazon): Todo falla eventualmente; la resiliencia viene de diseñar para esa realidad, no de desear que no ocurra.

Guía de diagnóstico rápido (haz esto primero)

Quieres señal rápida, no un viaje espiritual por los entresijos de LVM. Aquí está la ruta más corta a “qué está lleno, por qué y qué hacemos ahora mismo”.

Primero: confirma si es datos, metadata o ambos

Ejecuta lvs con los campos del thin pool. Si Data% está cerca del 100, necesitas liberar bloques o añadir espacio. Si Meta% está cerca del 100, necesitas extender/repairs de metadata y detener los desencadenantes de crecimiento (a menudo snapshots).

Segundo: identifica los mayores consumidores y los volúmenes “muertos”

Lista los thin LVs ordenados por bloques realmente usados. Luego cruza lo que Proxmox cree que existe con lo que LVM tiene. Los discos huérfanos son comunes tras restores fallidos, migraciones interrumpidas o manipulaciones manuales.

Tercero: detener la hemorragia

Pausar backups, restores, migraciones y trabajos con muchos snapshots mientras recuperas. Si no, estarás sacando agua con un agujero en el barco.

Cuarto: elige la acción de recuperación menos arriesgada

Eliminar snapshots innecesarios (victoria rápida).
Eliminar volúmenes verdaderamente huérfanos (gran ganancia, riesgo medio si te equivocas).
Habilitar/desaconsejar TRIM según la realidad (solución a más largo plazo).
Extender el thin pool (lo mejor si tienes espacio libre en el PV).

Hechos interesantes e historia breve (porque explica la rareza)

LVM existe en Linux desde la era 2.4, y LVM2 se convirtió en el enfoque estándar a medida que las distribuciones maduraron y los SANs se generalizaron.
LVM-thin llegó a principios de 2010 cuando Linux necesitó aprovisionamiento thin y snapshots sin añadir toda la pila de un sistema de archivos CoW.
La metadata del thin pool se guarda en disco, no solo en memoria; si está corrupta o llena, puedes terminar con comportamiento de solo-lectura o fallos de asignación.
El particionado por defecto de Proxmox históricamente favoreció “local + local-lvm” porque encajaba con flujos de trabajo comunes de VMs: almacenamiento de ISOs en filesystem, discos en block storage.
TRIM/Discard para aprovisionamiento thin fue controvertido durante años por rendimiento y problemas de corrección; ahora está mucho mejor, pero aún requiere habilitación intencional extremo a extremo.
Los snapshots son operativamente caros en casi todas las tecnologías de almacenamiento—LVM-thin, qcow2, arrays SAN—porque convierten sobreescrituras en operaciones de asignar y copiar.
El agotamiento de metadata a menudo aparece “de repente” porque no es proporcional a bytes escritos; es proporcional al mapeo de asignaciones y a la actividad de snapshots.
La sobreasignación es una característica de negocio tanto como técnica: mejora la utilización, pero es fundamentalmente una apuesta de que no todo crecerá a la vez.

Tareas prácticas: comandos, significado y decisiones (el meollo)

Más abajo hay tareas prácticas que puedes ejecutar en un nodo Proxmox. Cada tarea incluye: un comando, qué significa la salida y qué decisión tomar a partir de ella. Asume que tu host Proxmox es Debian-based y tienes root o sudo.

Tarea 1: Confirma la vista de almacenamiento de Proxmox vs la realidad

cr0x@server:~$ pvesm status
Name        Type     Status           Total            Used       Available        %
local        dir     active        98.00GB         12.40GB         80.60GB   12.65%
local-lvm    lvmthin active       700.00GB        699.20GB          0.80GB   99.89%

Significado: Proxmox cree que local-lvm está básicamente lleno. Ese es el síntoma, no el diagnóstico.

Decisión: Pasa inmediatamente a la vista de LVM. Proxmox reporta lo que LVM le dice; necesitas ver por qué está lleno (datos vs metadata, LVs thin más grandes, snapshots).

Tarea 2: Ver la salud del thin pool (datos y metadata)

cr0x@server:~$ lvs -o+lv_size,segtype,data_percent,metadata_percent,lv_attr,origin,pool_lv --units g
  LV                 VG  Attr       LSize   SegType  Data%  Meta%  Origin  Pool
  data               pve twi-aotz-- 650.00g thin-pool 99.85  12.40         data
  root               pve -wi-ao----  60.00g linear
  swap               pve -wi-ao----   8.00g linear

Significado: data es el thin pool. Data% está casi al 100%, Meta% está bien. Estás lleno por datos, no por metadata.

Decisión: Tus primeras opciones de recuperación son liberar bloques (eliminar snapshots/volúmenes) o extender el pool. La reparación de metadata no es el problema principal.

Tarea 3: Si la metadata es el problema, detectarlo explícitamente

cr0x@server:~$ lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr --units g
  LV              VG  LSize    Data%  Meta%  Attr
  data            pve 650.00g  78.10  99.60  twi-aotz--
  data_tmeta      pve   4.00g                 ewi-ao----
  data_tdata      pve 650.00g                 ewi-ao----

Significado: El uso de datos está aceptable, pero la metadata está cerca del 100%. Eso es “nos quedaremos sin espacio de mapeo pronto”, lo que puede ser peor que quedarse sin datos porque puede ocurrir mientras aún tienes bloques libres.

Decisión: Detén la churn de snapshots, considera extender la metadata y planifica una reparación si aparecen errores. No sigas escribiendo; así es como los thin pools se corrompen.

Tarea 4: Encuentra qué volúmenes thin están realmente consumiendo bloques

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent,lv_attr --units g --sort -data_percent
  LV                      LSize    Data%  Meta%  Attr
  vm-103-disk-0         200.00g   98.50         Vwi-aotz--
  vm-101-disk-0         150.00g   92.10         Vwi-aotz--
  vm-102-disk-0          80.00g   88.40         Vwi-aotz--
  vm-120-disk-0         500.00g   10.20         Vwi-aotz--

Significado: Data% aquí es el porcentaje de bloques asignados por LV thin relativo a su tamaño virtual. Los cercanos al 100% están casi “totalmente asignados”. Están consumiendo espacio real del pool.

Decisión: Identifica si estos son discos grandes legítimos haciendo trabajo real, o si algo anda mal: restores antiguos, VMs no usadas, snapshots olvidados.

Tarea 5: Mapear un volumen a una VM y su configuración

cr0x@server:~$ qm config 103
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: app-prod-03
scsi0: local-lvm:vm-103-disk-0,size=200G
ide2: local:iso/debian-12.iso,media=cdrom
net0: virtio=DE:AD:BE:EF:10:03,bridge=vmbr0

Significado: vm-103-disk-0 está adjunto a la VM 103. Ahora puedes coordinar la limpieza con los propietarios de la aplicación (o con tu yo futuro).

Decisión: Si la VM es crítica, no la borras. Buscas snapshots, limpieza dentro del huésped, o expansión. Si es una VM zombie, limpias agresivamente.

Tarea 6: Listar snapshots de una VM (los snapshots thin a menudo se ocultan aquí)

cr0x@server:~$ qm listsnapshot 103
`-> pre-upgrade-2024-11-15
    `-> before-hotfix
`-> backup-temp

Significado: Existen snapshots. Cada snapshot puede anclar bloques antiguos y forzar CoW en las escrituras, inflando el uso del pool.

Decisión: Si esos snapshots no son necesarios activamente, elimínalos. Conserva solo lo que puedas justificar en una frase.

Tarea 7: Eliminar un snapshot de forma segura

cr0x@server:~$ qm delsnapshot 103 backup-temp
Deleting snapshot 'backup-temp'...
TASK OK

Significado: Proxmox eliminó el snapshot. La liberación de espacio en LVM puede no ser inmediata si los bloques todavía son referenciados en otros lugares, pero muchas veces verás caer el uso del pool rápidamente.

Decisión: Revisa lvs. Si el espacio no se mueve, el pool está lleno por otras razones (o TRIM no está funcionando).

Tarea 8: Buscar LVs huérfanos (existen en LVM, no en configs de Proxmox)

cr0x@server:~$ pvesm list local-lvm
Volid                         Format  Type         Size VMID
local-lvm:vm-101-disk-0        raw     images 161061273600 101
local-lvm:vm-102-disk-0        raw     images  85899345920 102
local-lvm:vm-103-disk-0        raw     images 214748364800 103

cr0x@server:~$ lvs --noheadings -o lv_name pve | sed 's/^[ \t]*//'
data
root
swap
vm-101-disk-0
vm-102-disk-0
vm-103-disk-0
vm-999-disk-0

Significado: vm-999-disk-0 existe en LVM pero no está listado por Proxmox storage. Eso es sospechoso.

Decisión: Investiga antes de borrar. Podría ser un residuo de un restore fallido, o podría estar referenciado en una config antigua en otro nodo si hiciste algo creativo.

Tarea 9: Verificar si un LV sospechoso está referenciado en algún lugar

cr0x@server:~$ grep -R "vm-999-disk-0" /etc/pve/qemu-server /etc/pve/lxc 2>/dev/null || echo "no references found"
no references found

Significado: Las configs de Proxmox no lo mencionan. Esa es una señal fuerte de que está huérfano.

Decisión: Si además confirmas que no está montado/usado por nada más, puedes eliminarlo para recuperar espacio. Si no estás seguro, haz snapshot/backup de la metadata del host primero o renombra el LV como borrado suave.

Tarea 10: Borrado suave renombrando un LV (gana tiempo)

cr0x@server:~$ lvrename pve vm-999-disk-0 vm-999-disk-0.ORPHANED
  Renamed "vm-999-disk-0" to "vm-999-disk-0.ORPHANED" in volume group "pve"

Significado: Has quitado el nombre predecible sin destruir datos. Si algo se rompe, puedes renombrarlo de vuelta. Si nadie reclama nada, puedes borrarlo más tarde.

Decisión: Si estás bajo presión, renombrar es más seguro que borrar. Luego planifica la eliminación real en una ventana más calmada.

Tarea 11: Borrado duro de un LV huérfano para recuperar espacio

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

Significado: El thin LV ha sido eliminado. Eso libera los bloques referenciados en el thin pool.

Decisión: Revisa inmediatamente el uso del pool. Si baja significativamente, encontraste al devorador. Si no, sigue buscando.

Tarea 12: Confirmar cambio en el uso del pool

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent,lv_attr --units g
  LV    LSize    Data%  Meta%  Attr
  data  650.00g  92.30  12.45  twi-aotz--

Significado: Recuperaste espacio de datos: de ~99.8% a ~92.3%. No es perfecto, pero estás fuera de la zona de “fallo inminente”.

Decisión: No te quedes aquí. Los thin pools no perdonan la complacencia. Consigue un margen estable de libre (al menos 10–20% libre en nodos ocupados).

Tarea 13: Si tienes espacio libre en el VG, extiende el thin pool (solución más limpia)

cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   5   0 wz--n- 930.00g 280.00g

cr0x@server:~$ lvextend -L +200G /dev/pve/data
  Size of logical volume pve/data changed from 650.00 GiB (166400 extents) to 850.00 GiB (217600 extents).
  Logical volume pve/data successfully resized.

Significado: Tenías extents libres en el volume group y los usaste para extender el thin pool.

Decisión: Extender compra tiempo y reduce la presión operativa. Aun así, arregla la causa raíz; de lo contrario solo hiciste un recipiente más grande para la misma fuga.

Tarea 14: Extender metadata del thin pool si Meta% está alta

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

Significado: Más espacio de metadata para el thin pool. Esto suele ser necesario cuando has hecho muchos snapshots o tienes muchos thin volumes.

Decisión: Si estabas en Meta% > 90%, haz esto con prontitud. Luego reduce la churn de snapshots para no llenar también la nueva metadata.

Tarea 15: Comprobar si los discards están habilitados a nivel de thin pool

cr0x@server:~$ lvs -o lv_name,lv_attr,discards,zero
  LV    Attr       Discards  Zero
  data  twi-aotz-- passdown  yes

Significado: passdown significa que los discards desde los thin LVs pueden ser pasados al pool. Esto es bueno para la recuperación, asumiendo que el huésped realmente emite discards.

Decisión: Si los discards se ignoran y esperas TRIM, ajústalo. Si no quieres discards por características de la carga, acepta que la reclamación requiere otros métodos y más margen libre.

Tarea 16: Forzar fstrim dentro de un huésped Linux (donde ocurre la verdadera reclamación)

cr0x@server:~$ qm guest exec 103 -- fstrim -av
/boot: 0 B (0 bytes) trimmed
/: 24.6 GiB (26411479040 bytes) trimmed

Significado: El huésped informó al stack de almacenamiento qué bloques ya no usa. Si todo está cableado correctamente (virtio-scsi + discard habilitado + thin pool passdown), el uso del thin pool puede bajar.

Decisión: Si los trims recuperan espacio significativo, programa fstrim regularmente (o habilita discard continuo con cautela). Si los trims siempre devuelven 0 bytes, tienes una brecha de configuración.

Tarea 17: Si sospechas que el pool está atascado, revisa dmesg y errores thin

cr0x@server:~$ dmesg | tail -n 20
[12345.678901] device-mapper: thin: 253:2: reached low water mark of 32768 blocks
[12345.678950] device-mapper: thin: 253:2: no free space for data block

Significado: El objetivo thin del device-mapper se queja de bajo espacio / no hay bloques libres para datos. Si dice metadata en su lugar, es otra emergencia.

Decisión: Detén las escrituras (pausa backups/migraciones), libera espacio o extiende inmediatamente. Continuar con IO intenso aquí es cómo pasas de “incidente de almacenamiento” a “proyecto de recuperación de datos”.

Tarea 18: Identificar las mayores escrituras desde Proxmox (triaje rápido)

cr0x@server:~$ iotop -o -b -n 3 | head -n 20
Total DISK READ: 0.00 B/s | Total DISK WRITE: 48.32 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
 8421 be/4 root        0.00 B/s   22.10 M/s  0.00% 99.00%  vzdump --compress zstd 101
 9102 be/4 root        0.00 B/s   15.40 M/s  0.00% 97.00%  kvm -id 103 -name app-prod-03
 7766 be/4 root        0.00 B/s    9.90 M/s  0.00% 88.00%  kvm -id 102 -name db-prod-02

Significado: Los backups (vzdump) y VMs específicas están generando escrituras. En un thin pool casi lleno, ráfagas de escritura pueden llevarte por encima del límite muy rápido.

Decisión: Pausa los jobs de backup temporalmente. Si una VM en particular está escribiendo sin control (logs, archivos temporales, compactación), arréglalo en el huésped o limita su tasa.

Broma 1/2: Aprovisionamiento thin es como pedir una soda light con una hamburguesa triple—técnicamente posible, emocionalmente engañoso.

Encuentra qué devoró el pool: los sospechosos habituales

Sospechoso A: snapshots que vivieron demasiado

Los snapshots deben ser de corta duración. “Corta duración” significa horas o días, no trimestres. Una VM ocupada con un snapshot antiguo fuerza que cada bloque cambiado se copie, y esos bloques quedan anclados hasta que el snapshot se elimina.

Señal práctica: tu pool crece constantemente aunque los sistemas de archivos invitados digan que están estables. Otra señal: qm listsnapshot devuelve un árbol pequeño que oculta un coste CoW caro.

Sospechoso B: backups/restores/migraciones que dejaron basura

Proxmox suele limpiar bien. Pero si un nodo se cae durante un restore, un problema de almacenamiento interrumpe una migración, o una persona mata una tarea a la mitad, puedes obtener volúmenes thin huérfanos. Estos son consumidores “reales” e invisibles en vistas habituales de la UI a menos que compares pvesm list con lvs.

Realidad operacional: los volúmenes huérfanos son lo suficientemente comunes como para que reconciliar LVM vs configs de Proxmox sea un paso estándar en incidentes.

Sospechoso C: huéspedes que nunca hacen discard (TRIM no es automático)

Un thin pool solo aprende sobre bloques “liberados” si se emiten y propagan discards. Borrar 100 GB de archivos dentro de un huésped no necesariamente libera 100 GB en el thin pool. Sin discard/TRIM, el pool solo ve escrituras, nunca olvida asignaciones, y se acerca lentamente al 100%.

Los huéspedes Windows necesitan “Optimize Drives” programado (TRIM). Los huéspedes Linux necesitan fstrim periódico o opciones de montaje que soporten discard. Y el disco virtual/controlador debe soportarlo, además de que Proxmox no lo obstaculice.

Sospechoso D: qcow2 en el lugar equivocado (o raw con snapshots en otro lado)

En local-lvm (LVM-thin), Proxmox suele usar volúmenes raw, lo cual es bueno. Pero si almacenaste qcow2 en un almacenamiento de directorio (como local) y luego haces snapshots a nivel qcow2, obtienes una mecánica de crecimiento distinta. A veces los administradores migran discos entre almacenes y acaban con formatos inesperados y capas de snapshots.

Regla práctica: no apiles CoW sobre CoW a menos que estés probando sufrimiento deliberadamente.

Sospechoso E: una sola VM haciendo escrituras “legítimas” pero explosivas

Ejemplos comunes: bases de datos que hacen compactación, tormentas de logs, retención masiva de métricas o un huésped que escribe una imagen completa de backup en su propio disco. El aprovisionamiento thin empeora esto porque no sientes la presión hasta que ocurre.

Sospechoso F: presión de metadata por muchos snapshots o muchas asignaciones pequeñas

Aun si no estás escribiendo muchos bytes, puedes quemar metadata con churn de snapshots y patrones de asignación. El crecimiento de metadata puede parecer no relacionado con “GB usados”, por eso la gente se sorprende.

Arreglar ahora: movimientos de recuperación seguros

1) Pausar la churn

Detén backups programados, replicación y cualquier trabajo automatizado de snapshots. No hagas gimnasia de almacenamiento mientras algo sigue escribiendo fuerte.

cr0x@server:~$ systemctl stop pve-ha-lrm pve-ha-crm 2>/dev/null || true
cr0x@server:~$ systemctl stop cron 2>/dev/null || true

Significado: Esto es un instrumento contundente; úsalo con criterio. En clústeres, considera el impacto y coordina. El objetivo es reducir tareas en segundo plano que creen escrituras y snapshots.

Decisión: Si no puedes detener la automatización globalmente, al menos detén las tareas de backup/restore activas y evita iniciar nuevas hasta que el espacio esté estable.

2) Eliminar snapshots que no necesitas

Esta es la solución con mayor ROI cuando los snapshots son la causa. Elimínalos desde Proxmox para que limpie correctamente toda la cadena.

cr0x@server:~$ qm listsnapshot 101
`-> pre-upgrade
`-> weekly-safety

cr0x@server:~$ qm delsnapshot 101 weekly-safety
Deleting snapshot 'weekly-safety'...
TASK OK

Significado: La eliminación de snapshots puede tomar tiempo si la VM está activa y hay trabajo de merge. En LVM-thin suele ser más rápido que merges de qcow2, pero aún no es instantáneo si el IO es intenso.

Decisión: Revisa el uso del thin pool después de cada eliminación importante. No borres todo a ciegas si necesitas puntos de rollback para un cambio en curso.

3) Eliminar huérfanos (con cuidado)

Si tienes volúmenes que no están referenciados por ninguna config de VM, recupéralos. Prefiere renombrar primero si no estás seguro.

4) Extender el pool (si puedes)

Si tu VG tiene extents libres, extender /dev/pve/data es limpio y con poca ceremonia. Si no los tiene, puedes añadir un disco nuevo como PV y extender el VG—solo recuerda dominios de fallo y rendimiento.

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

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

cr0x@server:~$ lvextend -L +500G /dev/pve/data
  Size of logical volume pve/data changed from 850.00 GiB (217600 extents) to 1350.00 GiB (345600 extents).
  Logical volume pve/data successfully resized.

Significado: Aumentaste la capacidad del thin pool. Los datos respiran de inmediato.

Decisión: Extender no es sustituto de la limpieza. Si no arreglas al devorador, volverás a 100%—ahora a las 2 a.m. de un fin de semana, porque el almacenamiento tiene sentido del humor.

5) Abordar emergencias de metadata correctamente

Si la metadata está llena, la prioridad es evitar más consumo de metadata y recuperar margen. Extender metadata suele ser posible en línea, pero si el pool ya está en estado de error podrías necesitar herramientas de reparación y planificar downtime.

Revisa errores primero:

cr0x@server:~$ lvs -o lv_name,lv_attr,seg_monitor,devices pve
  LV    Attr       Cpy%Sync  Monitor  Devices
  data  twi-aotz--           monitored /dev/sda3(0)

Significado: El monitoreo puede ayudar a auto-extender en algunas configuraciones, pero no confíes en ello a menos que lo hayas configurado intencionalmente.

Decisión: Si Meta% es alta, extiende metadata y luego reduce la actividad de snapshots. Si ves errores de I/O, para y planifica una ventana de reparación.

6) Hacer TRIM real (extremo a extremo)

TRIM solo es útil si atraviesa toda la pila: filesystem del huésped → capa de bloques del huésped → disco virtual → capa de bloques del host → thin pool.

En Proxmox, asegúrate de que el disco use un controlador que soporte discard bien (virtio-scsi se usa comúnmente). En la config de la VM típicamente quieres discard habilitado. Luego programa fstrim en los huéspedes.

Prevenir la repetición: controles aburridos que funcionan

Margen libre es una política, no una esperanza

El aprovisionamiento thin está bien. Ejecutar un thin pool al 90–95% en un nodo ocupado no está bien. Tu margen operativo seguro depende de la tasa de escritura y la velocidad de recuperación. En la mayoría de entornos de producción quiero al menos 15–20% de datos libres en thin pools que albergan VMs con escrituras intensas.

Higiene de snapshots: límites temporales, no sentimientos

Pon TTL a los snapshots. Si un snapshot existe más tiempo del motivo por el que fue creado, no es “seguridad”, es deuda técnica silenciosa.

Reconciliación regular: LVM vs Proxmox

Una vez al mes (o después de cualquier incidente con restores/migraciones), compara los volúmenes thin con las configs de VM. Detecta huérfanos mientras son pequeños y no estás bajo presión.

Programación de trim en huéspedes

Para huéspedes Linux, un fstrim.timer semanal suele ser suficiente. Para Windows, programa Optimize Drives (TRIM). Para bases de datos, coordina con ventanas de mantenimiento si te preocupa el pico de IO.

Alertar sobre Data% y Meta% por separado

La mayoría de stacks de alertas sólo vigilan “uso de almacenamiento”. Eso falla en detectar metadata. Si alertas al 80/90% para datos pero nunca para metadata, estás mirando el acantilado equivocado.

Broma 2/2: Un thin pool al 100% es la forma que tiene la naturaleza de recordarte que “ilimitado” siempre fue marketing.

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

1) Síntoma: local-lvm muestra 100%, pero “df -h” se ve bien

Causa raíz: local-lvm es almacenamiento en bloque; df informa uso de sistemas de archivos montados, no el consumo del thin pool LVM-thin.

Solución: Usa lvs y pvesm status. Trata Data% y Meta% como métricas de primera clase.

2) Síntoma: las escrituras de la VM fallan o el sistema de archivos se vuelve solo-lectura durante un backup

Causa raíz: thin pool lleno de datos; los picos de backup (snapshots, volúmenes temporales, sobrecarga CoW) generan escrituras.

Solución: Detén backups, libera espacio (snapshots/huérfanos) o extiende el pool. Luego vuelve a ejecutar backups con margen libre.

3) Síntoma: el thin pool tiene espacio, pero nuevas asignaciones fallan

Causa raíz: metadata llena (Meta% alta) o errores de metadata.

Solución: Extiende metadata (lvextend --poolmetadatasize) y reduce la churn de snapshots. Investiga errores thin en dmesg.

4) Síntoma: borraste muchos archivos dentro de una VM, pero el uso del pool no bajó

Causa raíz: no hay propagación de TRIM/discard; los bloques permanecen asignados en el thin pool.

Solución: Habilita discard extremo a extremo y ejecuta fstrim en el huésped. Valida con bytes recuperados y cambio en uso del pool.

5) Síntoma: el uso del pool sigue creciendo aunque las VMs estén “inactivas”

Causa raíz: snapshots anclan bloques; trabajos en segundo plano (rotación de logs, antivirus, indexación) reescriben datos; la herramienta de backups crea churn de snapshots.

Solución: Elimina snapshots antiguos, reduce trabajos churn y deja de almacenar “snapshots para siempre” en thin pools de producción.

6) Síntoma: el pool se llenó “de la noche a la mañana” después de redimensionar un disco de VM

Causa raíz: sobreaprovisionamiento thin más expansión del filesystem del huésped, o un restore escribió una imagen completa en el volumen thin.

Solución: Audita la sobreasignación. Pon límites al crecimiento, aumenta margen libre y alerta antes.

Listas de verificación / plan paso a paso

Paso a paso: recuperar local-lvm al 100% (riesgo mínimo)

Confirma si es data o metadata lo que está lleno (lvs -o data_percent,metadata_percent).
Pausa tareas de backup/restore/migración que crean churn.
Lista el uso por disco de cada VM (LVM thin LVs) e identifica los mayores consumidores.
Revisa snapshots en los mayores consumidores; elimina snapshots no esenciales primero.
Vuelve a comprobar el uso del pool tras cada eliminación.
Busca volúmenes huérfanos comparando pvesm list y lvs.
Renombra huérfanos como paso de seguridad; elimina después de confirmar.
Si el VG tiene espacio libre, extiende el thin pool y/o la metadata.
Habilita y valida TRIM extremo a extremo; ejecuta fstrim en los huéspedes.
Reinicia los jobs pausados solo después de haber restaurado margen libre.

Lista operativa: prevenir recurrencias

Alertar por separado sobre Data% y Meta% del thin pool.
Establecer una política TTL para snapshots y hacerla cumplir (la automatización ayuda).
Escaneo mensual de huérfanos: reconciliar volúmenes LVM con configs de Proxmox.
Revisión trimestral de capacidad: ratio de sobreaprovisionamiento thin, tendencias de crecimiento y escenario “peor caso crecimiento simultáneo”.
Programar trim en huéspedes: verificarlo con bytes realmente recuperados, no con buenas intenciones.

Tres mini-historias corporativas desde las trincheras del thin pool

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

Tenían un pequeño clúster Proxmox con servicios internos: agentes de build, almacenamiento de artefactos, un par de VMs de bases de datos y entornos de prueba “temporales” que se volvieron muy permanentes. El equipo vigilaba el uso de disco mediante una métrica estándar del host: el porcentaje de uso del filesystem en /. Permanecía en verde.

Entonces, un lunes por la mañana, varias VMs se volvieron solo-lectura. El job de backup falló. La UI lanzó errores que parecían problemas de permisos. El on-call hizo lo que hacen los on-calls: reinició la VM que más ruido hacía primero. Volvió peor.

La suposición equivocada fue simple: “Si el filesystem del host tiene espacio, el almacenamiento de las VMs tiene espacio.” Pero local-lvm era su propio thin pool, separado de /. El thin pool había alcanzado el 100% tarde el domingo durante una ventana de backup silenciosa—silenciosa para humanos, no para el almacenamiento.

La recuperación fue sencilla una vez que miraron en el lugar correcto: lvs mostraba data al 99.9%. Un snapshot de larga duración en una VM de base de datos con muchas escrituras estaba anclando bloques. Eliminar el snapshot liberó suficiente espacio para estabilizar, luego extendieron el pool y añadieron alertas para Data% y Meta%.

Lo que cambió culturalmente fue mejor: dejaron de tratar el aprovisionamiento thin como “almacenamiento extra mágico” y empezaron a tratarlo como una herramienta de planificación de capacidad con riesgo explícito. El incidente no fue causado por LVM-thin. Fue causado por una suposición que nadie había documentado, así que nadie la cuestionó.

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

Otra empresa quería backups más rápidos. Alguien notó que los backups basados en snapshots eran “instantáneos” en el paso del snapshot, y razonó que podían tomar snapshots más frecuentemente para reducir el RPO. Automatizaron un snapshot cada hora para VMs clave y los conservaron dos semanas. En papel parecía responsable.

La primera semana fue bien. La segunda, el rendimiento se volvió raro: picos de latencia, stalls de I/O ocasionales y un uso de almacenamiento creciente que no coincidía con el crecimiento de la aplicación. El thin pool no solo se llenaba; lo hacía en un patrón correlacionado con jobs por lotes con muchas escrituras.

Snapshots horarias implicaban CoW constante. La “optimización” aumentó la amplificación de escritura, quemó metadata más rápido y ancló bloques antiguos durante dos semanas—justo el tiempo suficiente para convertir churn normal en asignación persistente. No habían reducido los backups; habían añadido un mecanismo de retención parecido a un backup dentro de la capa de almacenamiento.

Volvieron a un enfoque más sensato: un snapshot de corta vida antes de cambios durante ventanas de mantenimiento, más backups reales con restores probados. La frecuencia de snapshots bajó, el rendimiento se estabilizó y el thin pool dejó de comportarse como un globo que se inflaba lentamente.

Conclusión: los snapshots no son un sistema de backup gratuito. Son una herramienta precisa para rollback a corto plazo. Úsalos como bisturí, no como archivo.

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

Un equipo cercano a finanzas (del tipo que hace felices a los auditores y molesta ligeramente a los ingenieros) gestionaba Proxmox para unas pocas docenas de VMs. Su enfoque era poco sexy: umbrales de capacidad, reglas de margen libre y housekeeping programado. Cada VM tenía un propietario documentado. Cada snapshot tenía una expiración.

Una tarde, una prueba de restore salió mal. Un restore grande se interrumpió a mitad de transmisión por un fallo de red. El operador reintentó y el segundo intento tuvo éxito. Nadie notó que el primer intento dejó un thin LV huérfano.

Dos semanas después, el job mensual de “reconciliación de almacenamiento” marcó un LV presente en LVM pero no referenciado por ninguna config de Proxmox. El informe no borró nada automáticamente; solo creó un ticket con el nombre del LV, tamaño y hora de creación. Alguien verificó que no estaba referenciado y lo eliminó. El espacio volvió.

Nada se rompió. Sin caída. Sin limpieza de emergencia. Sin fin de semana arruinado.

La práctica no fue ingeniosa. Fue lo opuesto: auditoría rutinaria con sesgo hacia acciones seguras (renombrar primero, luego borrar). Ese aburrimiento evitó un futuro incidente de thin pool al 100% en un día en que el equipo ya estaba ocupado con otros desastres.

Preguntas frecuentes

¿Por qué local-lvm llega al 100% si mis VMs aún muestran espacio libre dentro?

Porque el uso del thin pool rastrea bloques asignados, no el “espacio libre” del huésped. Borrar archivos en el huésped puede no devolver bloques sin TRIM/discard. Los snapshots también pueden anclar bloques.

¿local-lvm es lo mismo que LVM en el disco raíz del host?

No. Normalmente es un LV thin dentro de un VG (a menudo pve), separado del LV del filesystem raíz. Contabilidad distinta, modos de fallo distintos.

¿Qué es más peligroso: Data% al 99% o Meta% al 99%?

Ambos son malos. La metadata al 99% puede ser más traicionera porque las asignaciones pueden fallar inesperadamente y la recuperación puede ser más delicada. Trata cualquiera de los dos como un incidente.

¿Puedo simplemente eliminar “discos no usados” desde la GUI?

Puedes eliminar discos no usados que Proxmox conoce. Lo peligroso son los volúmenes que Proxmox no lista (huérfanos). Para esos, reconciliar configs primero; renombrar antes de borrar es un buen patrón de seguridad.

¿Por qué eliminar un snapshot no liberó espacio inmediatamente?

Si otros snapshots aún referencian bloques, o si la carga de trabajo reescribió bloques intensamente, el espacio puede no bajar mucho. Además, podrías estar lleno por otros volúmenes, no por snapshots.

¿Habilitar discard perjudica el rendimiento?

Puede, dependiendo de la carga y del almacenamiento subyacente. Muchos entornos van bien con fstrim periódico en lugar de discard continuo. Mide en tu hardware.

¿Cómo sé qué VM consume más espacio?

Usa lvs ordenado por Data% por LV y tamaño, y mapea volúmenes a VMs con qm config <vmid>. También revisa snapshots y backups por picos de escritura.

¿Puedo reducir un thin LV para recuperar espacio en el pool?

No de forma segura como primera medida. Reducir discos virtuales requiere shrink de filesystem dentro del huésped y operaciones cuidadosas a nivel de bloque. Prefiere eliminar snapshots/huérfanos, trim o extender el pool.

¿Debería mover discos de VM fuera de local-lvm a otro almacenamiento?

Si necesitas reclaación predecible, replicación y visibilidad, considera almacenamiento con primitivas de gestión más fuertes (o separar almacenamiento por niveles). Pero local-lvm está bien si impones margen libre, TTL de snapshots y trimming.

¿Cuál es el movimiento más rápido “necesito espacio ahora”?

Eliminar snapshots innecesarios y quitar volúmenes huérfanos confirmados. Si tienes espacio libre en el VG, extender el thin pool también es una acción rápida y de bajo riesgo.

Conclusión: siguientes pasos que deberías hacer

Cuando local-lvm de Proxmox llega al 100%, la solución rara vez es mística. Normalmente es una de cuatro cosas: snapshots que se excedieron, volúmenes huérfanos, falta de TRIM o simplemente falta de capacidad. La ventaja viene de diagnosticar cuál antes de empezar a borrar cosas de las que luego te arrepientas.

Haz esto a continuación:

Ejecuta lvs y anota Data% y Meta%. Esa es tu verdad base.
Elimina snapshots que no necesites, empezando por las VMs más activas.
Reconcilia pvesm list vs lvs y elimina huérfanos confirmados (renombra primero si eres cauto).
Extiende el thin pool si tienes espacio en el VG; extiende metadata si Meta% está alta.
Haz TRIM real: habilítalo extremo a extremo y verifica los bytes recuperados con fstrim.
Configura alertas y una política TTL de snapshots para no volver a pasar por esto bajo presión.