Instantánea de Proxmox atascada: limpieza segura de restos en LVM-thin

diciembre 17, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 7

¿Te fue útil?

Haces clic en “Delete snapshot” en Proxmox. La tarea gira. Luego falla. O peor: dice que tuvo éxito, pero el almacenamiento todavía muestra volúmenes fantasma, tu thin pool sigue hinchado y las copias de seguridad siguen tropezando con la misma mina.

Esta es la cruda realidad de LVM-thin en un clúster de virtualización ocupado: las instantáneas son baratas hasta que dejan de serlo, y la limpieza es segura solo si entiendes qué está realmente asignado, qué está meramente referenciado y qué está directamente huérfano.

El modelo mental: cómo funcionan realmente las instantáneas en Proxmox + LVM-thin

Si tratas la “instantánea” como una máquina del tiempo mágica, acabarás eliminando lo equivocado. Trátala como fontanería de almacenamiento con conteos de referencias y comportamiento copy-on-write y dormirás mejor.

Qué hace Proxmox cuando pulsas “Snapshot”

Para almacenamiento LVM-thin (lvmthin en Proxmox), un disco de VM típicamente es un volumen thin dentro de un thin pool. Una instantánea es otro volumen thin que comparte bloques con el volumen origen. Las escrituras van a otro sitio; las lecturas pueden venir de los bloques compartidos o de los bloques delta. Ese “otro sitio” sigue siendo tu thin pool. La provisión thin no es espacio libre; es facturación diferida.

Proxmox rastrea instantáneas en la configuración de la VM (/etc/pve/qemu-server/<vmid>.conf) y usa herramientas LVM debajo. Cuando la eliminación de una instantánea falla, a menudo terminas con un desacuerdo entre:

Inventario de Proxmox (lo que cree que existe)
Realidad de LVM (qué volúmenes thin existen y quién referencia a quién)
Estado de device-mapper (qué está activo, abierto o suspendido)

Cómo se ven los “restos” en LVM-thin

Los restos aparecen como volúmenes thin que ya no tienen una referencia correspondiente en la configuración de la VM, o como volúmenes de instantánea cuyo origen ha sido eliminado, o como volúmenes que Proxmox querría eliminar pero LVM se niega porque algo todavía los tiene abiertos.

Patrones comunes de restos:

LV thin de instantánea huérfano: el registro de instantánea de la VM desapareció, pero el LV thin permanece.
Disco base huérfano: el disco de la VM se movió o eliminó a nivel de Proxmox, pero el LV thin sigue existiendo.
Dispositivos “ocupados”: qemu, qemu-nbd, herramientas de backup o incluso mapeos device-mapper obsoletos mantienen el LV abierto.
Presión de metadatos del thin pool: las eliminaciones y fusiones se vuelven lentas o fallan cuando los metadatos están casi llenos o el pool está corrupto.

Una cita, porque sigue siendo cierta

Idea parafraseada (Werner Vogels): debes prepararte para el fallo como condición normal de operación, no como una excepción rara.

Guía rápida de diagnóstico (verifica 1/2/3)

No deambules. No “simplemente reinicies el nodo” a menos que puedas tolerar una caída y sepas qué dispositivos están abiertos. Haz esto en su lugar.

1) Comprueba si Proxmox está atascado por sus propios locks o por una tarea en ejecución

¿Hay una tarea en ejecución para eliminar/restaurar la instantánea?
¿Hay un lock obsoleto en la configuración de la VM?
¿Estás compitiendo con una copia de seguridad (vzdump) o un trabajo de replicación?

2) Comprueba la salud del thin pool LVM y el uso de metadatos

¿Los datos o metadatos del thin pool están cerca del 100%?
¿Hay advertencias sobre IDs de transacción, needs-check o comportamiento de solo lectura?
¿Está reaccionando dmeventd/lvmmonitor, o ha sido deshabilitado?

3) Identifica quién mantiene el LV abierto

¿Sigue ejecutándose qemu?
¿Sigue activo un dispositivo mapper?
¿Algo como qemu-nbd o un montaje obsoleto lo mantiene?

Una vez que sepas cuál de estos tres es el cuello de botella, la limpieza se vuelve mayormente mecánica. Si no lo sabes, cada comando es una moneda al aire.

Hechos y contexto interesantes (porque la historia se repite)

Las instantáneas de LVM son anteriores a la provisión thin. Las instantáneas clásicas de LVM consumían espacio y eran lentas bajo cargas intensas de escritura; las instantáneas thin cambiaron el perfil de rendimiento pero no los bordes operativos afilados.
Device-mapper es el motor real. LVM es la orquestación en espacio de usuario; el device-mapper del kernel Linux hace el mapeo real, el seguimiento de referencias y el comportamiento de provisión thin.
Los metadatos del thin pool son su propio “disco”. Cuando los metadatos se llenan, el pool puede cambiar a solo lectura para evitar corrupción. Las eliminaciones pueden volverse imposibles justo cuando necesitas espacio.
Eliminar instantáneas puede ser costoso. La eliminación de instantáneas thin puede desencadenar descartes de bloques y actualizaciones de metadatos, que no son “gratis”, especialmente en pools ocupados.
Proxmox usa el estado de configuración como verdad. Si la configuración y el almacenamiento divergen, la interfaz puede mentir con cara seria. El sistema no es malicioso; solo lee un libro diferente al de LVM.
La provisión thin puede ocultar riesgo. El overcommit funciona hasta que no; el modo de fallo es abrupto y feo, y suele ocurrir durante operaciones intensivas en instantáneas.
Los kernels más antiguos tenían peores historias de reparación thin. Las herramientas de metadatos thin mejoraron con el tiempo, pero la reparación sigue siendo el tipo de “éxito” que viene con dolor de cabeza y un postmortem.
Las tormentas de instantáneas existen de verdad. Los ciclos repetidos de crear/eliminar instantáneas pueden fragmentar metadatos y amplificar la latencia de formas que sorprenden a quienes solo miran gráficos de IOPS.

Broma #1: Una instantánea es como una suscripción al gimnasio: barata de crear, misteriosamente cara de quitar.

Tareas prácticas con comandos: diagnosticar, decidir, actuar

Estas tareas están ordenadas como realmente las ejecuto en producción: demuestra qué está pasando, reduce el radio de explosión y luego borra cosas con confianza.

Tarea 1: Confirma el tipo de almacenamiento y el nombre que usa Proxmox

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        197919072        45121480       142663256   22.80%
local-lvm      lvmthin    active        9996536384      7125647360      2870889024   71.28%

Qué significa: Tienes un almacenamiento lvmthin llamado local-lvm. Los restos de instantáneas serán LVs thin dentro del VG que respalda este almacenamiento (comúnmente pve).

Decisión: Usa herramientas LVM-thin, no herramientas ZFS, no “eliminar archivos al azar”. Tu camino de limpieza es lvs/lvremove/dmsetup, más la higiene de configuración de Proxmox.

Tarea 2: Identifica la VM y verifica si Proxmox cree que existe una instantánea

cr0x@server:~$ qm listsnapshot 104
`-> current
   `-> pre-upgrade-2025w51  2025-12-18 02:14:09  VM snapshot
   `-> before-agent-change  2025-12-20 11:07:55  VM snapshot

Qué significa: Proxmox cree que existen instantáneas. Si la eliminación falla, o LVM se negó, o el estado de Proxmox divergió a mitad de la operación.

Decisión: Si Proxmox lista instantáneas, prefiere eliminar vía qm delsnapshot primero. Las eliminaciones manuales de LVM son para cuando el estado ya es inconsistente o Proxmox está atascado.

Tarea 3: Busca locks en la configuración de VM que bloqueen operaciones de instantánea

cr0x@server:~$ grep -E '^(lock:|snapshots:)' /etc/pve/qemu-server/104.conf
lock: snapshot

Qué significa: La VM está bloqueada para una operación de instantánea. Esto podría ser legítimo (todavía en curso) o obsoleto (la tarea murió).

Decisión: Si no hay una tarea en ejecución y el lock está obsoleto, desbloquea la VM antes de reintentar eliminar. Si hay una tarea en ejecución, deténla e investiga primero.

Tarea 4: Comprueba el historial de tareas de Proxmox para la operación que falla

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy --since "2 hours ago" | tail -n 30
Dec 26 09:10:14 server pvedaemon[2214]: starting task UPID:server:0000B5AA:0001B2C1:676D6E46:qmddelsnapshot:104:root@pam:
Dec 26 09:10:16 server pvedaemon[2214]: command 'lvremove -f pve/vm-104-disk-0-pre--upgrade--2025w51' failed: exit code 5
Dec 26 09:10:16 server pvedaemon[2214]: error: Logical volume pve/vm-104-disk-0-pre--upgrade--2025w51 contains a filesystem in use.
Dec 26 09:10:16 server pvedaemon[2214]: TASK ERROR: command 'lvremove -f pve/vm-104-disk-0-pre--upgrade--2025w51' failed: exit code 5

Qué significa: Esto no es “rareza de la UI de Proxmox”. LVM se negó porque el dispositivo está “en uso”. Eso suele ser un descriptor de archivo abierto, un dispositivo mapper obsoleto o qemu que todavía lo referencia.

Decisión: Identifica el proceso que lo mantiene. No fuerces la eliminación hasta saber qué significa “en uso”.

Tarea 5: Encuentra los volúmenes thin LVM para la VM y mapea nombres de instantánea a LVs

cr0x@server:~$ lvs -a -o vg_name,lv_name,lv_attr,origin,devices,lv_size,data_percent,metadata_percent pve | grep -E 'vm-104'
pve  vm-104-disk-0                             Vwi-aotz--                                    thinpool           200.00g  78.12
pve  vm-104-disk-0-pre--upgrade--2025w51       Vwi---tz-k  vm-104-disk-0                     thinpool           200.00g  12.44
pve  vm-104-disk-0-before--agent--change       Vwi---tz-k  vm-104-disk-0                     thinpool           200.00g   3.02

Qué significa: Tienes el disco base y dos instantáneas thin. origin apunta al base. Los atributos (Vwi---) indican que son volúmenes thin y activos.

Decisión: Si los LVs existen, Proxmox no está alucinando. Si Proxmox cree que existe una instantánea pero falta aquí, estás lidiando con divergencia y necesitarás arreglar el estado de configuración.

Tarea 6: Inspecciona la salud del thin pool (uso de datos + metadatos)

cr0x@server:~$ lvs -o vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent pve
VG   LV        Attr       LSize   Data%  Meta%
pve  root      -wi-ao----  96.00g
pve  swap      -wi-ao----   8.00g
pve  thinpool  twi-aotz--   7.30t  71.28  92.10

Qué significa: Metadatos al 92% es una luz amarilla intermitente. La agotación de metadatos del thin causa fallos extraños: las eliminaciones se cuelgan, el pool se vuelve solo lectura, las asignaciones fallan y aprendes nuevas palabras malsonantes.

Decisión: Si los metadatos >80%, prioriza la limpieza y/o la extensión de metadatos antes de un churn agresivo de instantáneas. Si >95%, trátalo como un incidente.

Tarea 7: Comprueba si la VM está en ejecución y podría seguir referenciando dispositivos de instantánea

cr0x@server:~$ qm status 104
status: running

Qué significa: Una VM en ejecución puede mantener dispositivos abiertos. La eliminación de instantáneas normalmente apunta a volúmenes de instantánea, pero según la operación (rollback, backup, clonación), pueden existir mapeos adicionales.

Decisión: Para una limpieza segura, planifica una ventana de mantenimiento para detener la VM si necesitas eliminar LVs que reclaman “en uso”. Si no puedes detenerla, debes demostrar que ninguna ruta crítica aún referencia el LV.

Tarea 8: Encuentra quién tiene abierto el LV (lsof/fuser en la ruta del dispositivo)

cr0x@server:~$ lsof /dev/pve/vm-104-disk-0-pre--upgrade--2025w51 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 915 root   49u  BLK  253,7      0t0  891 /dev/dm-7

Qué significa: qemu tiene el dispositivo abierto. LVM tiene razón en negarse a eliminar.

Decisión: Averigua por qué qemu mantiene abierto un LV de instantánea. Comúnmente: un trabajo de bloques, una copia de seguridad o un intento de rollback. No mates qemu a ciegas a menos que hayas aceptado el impacto en la VM.

Tarea 9: Mapea nodos device-mapper a nombres humanos

cr0x@server:~$ dmsetup ls --tree | sed -n '1,80p'
pve-thinpool (253:2)
 ├─pve-vm--104--disk--0 (253:3)
 ├─pve-vm--104--disk--0--pre--upgrade--2025w51 (253:7)
 └─pve-vm--104--disk--0--before--agent--change (253:8)

Qué significa: La instantánea es un dispositivo dm. Si está abierto, dm no permitirá que LVM lo elimine limpiamente.

Decisión: Usa este mapeo para confirmar exactamente qué está abierto y evita pensar al estilo “rm -rf”. También puedes usar dmsetup info para verificar el conteo abierto.

Tarea 10: Comprueba el conteo abierto en el dispositivo problemático

cr0x@server:~$ dmsetup info -c /dev/mapper/pve-vm--104--disk--0--pre--upgrade--2025w51
Name  Maj Min Stat Open Targ Event  UUID
pve-vm--104--disk--0--pre--upgrade--2025w51 253 7 L--w 1 1 0 LVM-6l3B0bQyQq0yYV3uQ0sG0fQxY3o2mV3S

Qué significa: Open es 1. Algo lo tiene. Eso explica el fallo de lvremove.

Decisión: Encuentra y detén el poseedor (preferido), o termina la operación que lo mantiene, y luego reintenta la eliminación. Si Open es 0 y lvremove aún falla, estás ante mapeos obsoletos o rarezas de metadatos LVM.

Tarea 11: Comprueba si hay trabajos de backup o copias basadas en instantáneas en ejecución

cr0x@server:~$ ps aux | grep -E 'vzdump|qemu-nbd|pbs-client' | grep -v grep
root     18444  2.1  0.1  35472 12896 ?        Ss   09:05   0:16 vzdump 104 --mode snapshot --compress zstd

Qué significa: El trabajo de backup puede haber creado mapeos temporales de instantánea o puede estar manteniendo dispositivos abiertos durante la transferencia.

Decisión: Deja que el backup termine o detenlo limpiamente si está bloqueado. Eliminar instantáneas a mitad de un backup es una excelente forma de fabricar alegaciones de corrupción.

Tarea 12: Intenta la eliminación soportada (tras eliminar la causa raíz)

cr0x@server:~$ qm delsnapshot 104 pre-upgrade-2025w51
delete snapshot 'pre-upgrade-2025w51'
TASK OK

Qué significa: Proxmox gestionó la eliminación, actualizó el estado de la configuración y pidió a LVM que eliminara el LV correcto.

Decisión: Vuelve a comprobar el uso del thin pool y que el LV haya desaparecido realmente. “TASK OK” es necesario, no suficiente.

Tarea 13: Verifica que el LV se haya eliminado realmente (confía, luego verifica)

cr0x@server:~$ lvs -a pve | grep -E 'vm-104-disk-0-pre--upgrade'

Qué significa: Ninguna salida significa que el LV se eliminó.

Decisión: Si aún está presente, tienes una falla parcial: el estado de Proxmox dice “eliminado” pero LVM no lo hizo. Ahí comienza la limpieza manual, y la haces con cuidado.

Tarea 14: Encuentra volúmenes “desconocidos” desde la perspectiva de Proxmox

cr0x@server:~$ pvesm list local-lvm | grep -E 'vm-104|unused|snap' | head -n 20
local-lvm:vm-104-disk-0        vmimage 200.00g
local-lvm:vm-104-disk-0-before--agent--change  vmimage 200.00g

Qué significa: Proxmox todavía ve la instantánea “before-agent-change” como una imagen de VM. Eso puede ser correcto o un resto dependiendo de lo que diga qm listsnapshot.

Decisión: Si Proxmox no lista la instantánea pero pvesm list sí, trátala como candidata a huérfana y confirma referencias antes de eliminar.

Tarea 15: Revisa la configuración de la VM en busca de discos “unused” que apunten a LVs antiguos

cr0x@server:~$ grep -E '^(scsi|virtio|sata|unused)[0-9]+:' /etc/pve/qemu-server/104.conf
scsi0: local-lvm:vm-104-disk-0,size=200G
unused0: local-lvm:vm-104-disk-0-before--agent--change

Qué significa: Proxmox a veces aparca volúmenes ya no adjuntos como unusedX. Esto es una forma educada de acaparamiento.

Decisión: Si realmente está unused, elimínalo mediante Proxmox para que actualice su inventario y luego valida con LVM.

Tarea 16: Elimina un disco unused de forma segura con herramientas de Proxmox

cr0x@server:~$ qm unused 104
unused0: local-lvm:vm-104-disk-0-before--agent--change

cr0x@server:~$ qm set 104 --delete unused0
update VM 104: -delete unused0

Qué significa: La referencia de configuración se elimina. Dependiendo del almacenamiento y ajustes, el LV subyacente puede seguir existiendo hasta que lo elimines explícitamente.

Decisión: Ahora elimina el volumen vía pvesm free (preferido) o lvremove (solo si confirmaste que está huérfano).

Tarea 17: Liberar un volumen usando el gestor de almacenamiento de Proxmox

cr0x@server:~$ pvesm free local-lvm:vm-104-disk-0-before--agent--change
successfully removed 'local-lvm:vm-104-disk-0-before--agent--change'

Qué significa: Proxmox pidió al backend eliminar el LV y actualizó su estado interno.

Decisión: Si esto falla con “volume is busy”, vuelve a conteo abierto y procesos que lo mantienen. Forzar la eliminación aquí es como conseguir sorpresas a las 3 a.m.

Tarea 18: Si Proxmox está fuera de sincronía, localiza huérfanos verdaderos escaneando LVM por volúmenes que empiecen por “vm-” sin configs

cr0x@server:~$ ls /etc/pve/qemu-server | sed 's/\.conf$//' | sort -n | tail -n 5
101
102
104
110
132

cr0x@server:~$ lvs --noheadings -o lv_name pve | awk '{print $1}' | grep '^vm-' | head
vm-101-disk-0
vm-102-disk-0
vm-104-disk-0
vm-999-disk-0-oldsnap

Qué significa: vm-999-... existe en LVM pero no hay 999.conf. Esa es una candidata a huérfana.

Decisión: Antes de eliminar, confirma que no está referenciada por otra VM (clones enlazados, cadenas de plantillas) y que no la usa replicación o herramientas de backup.

Tarea 19: Confirma si una candidata huérfana está referenciada en algún config de Proxmox

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

Qué significa: Ninguna salida sugiere que no hay referencias en la configuración de VM.

Decisión: Aun así verifica que no esté abierta y que no sea parte de una cadena origen/instantánea que te importe.

Tarea 20: Verifica relaciones snapshot/origin para una candidata huérfana

cr0x@server:~$ lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent pve | grep -E 'vm-999|Origin'
vm-999-disk-0-oldsnap              Vwi---tz-k  vm-999-disk-0                 100.00g  24.11
vm-999-disk-0                      Vwi-aotz--                                   100.00g  88.02

Qué significa: El LV “oldsnap” es una instantánea de vm-999-disk-0. Si vm-999-disk-0 también está huérfano, puedes eliminar ambos—pero el orden importa y debes verificar conteos abiertos.

Decisión: Elimina las instantáneas primero, luego los orígenes, a menos que tengas una razón (y pruebas) para hacerlo al revés.

Tarea 21: Confirma que nadie tiene abierto el LV huérfano

cr0x@server:~$ dmsetup info -c /dev/mapper/pve-vm--999--disk--0--oldsnap
Name  Maj Min Stat Open Targ Event  UUID
pve-vm--999--disk--0--oldsnap 253 22 L--w 0 1 0 LVM-0bqVtQyS2L3kVJrQ9xF5jH1gYd2nM3p

Qué significa: El conteo Open es 0. Bien.

Decisión: Puedes eliminarlo, pero hazlo de forma que mantenga consistencia en los metadatos de LVM y facilite la auditoría.

Tarea 22: Elimina un LV huérfano con LVM directamente (solo después de probar que está huérfano)

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

Qué significa: El LV de instantánea se eliminó. Si era el resto, deberías ver el uso del thin pool bajar con el tiempo (a veces no instantáneamente si los descartes son diferidos).

Decisión: Vuelve a comprobar uso y metadatos del pool. Si los metadatos siguen peligrosamente altos, planea una extensión de metadatos o una ventana de mantenimiento para una limpieza más profunda.

Tarea 23: Vuelve a comprobar el estado del thin pool después de la limpieza

cr0x@server:~$ lvs -o lv_name,data_percent,metadata_percent pve/thinpool
LV       Data%  Meta%
thinpool 69.90  88.40

Qué significa: Los metadatos bajaron del 92% al 88%. Eso es significativo. El alivio de metadatos a menudo importa más que el uso de datos bruto cuando las eliminaciones fallan.

Decisión: Si los metadatos siguen altos, sigue podando instantáneas y considera extender la metadata del thin.

Tarea 24: Extiende la metadata del thin pool (con cuidado) cuando estés cerca del borde

cr0x@server:~$ lvdisplay pve/thinpool | grep -E 'LV Size|Pool metadata'
LV Size                7.30 TiB
Pool metadata          thinpool_tmeta

cr0x@server:~$ lvs -o lv_name,lv_size pve | grep thinpool_tmeta
thinpool_tmeta  16.00g

cr0x@server:~$ lvextend -L +4G pve/thinpool_tmeta
Size of logical volume pve/thinpool_tmeta changed from 16.00 GiB (4096 extents) to 20.00 GiB (5120 extents).
Logical volume pve/thinpool_tmeta successfully resized.

cr0x@server:~$ lvconvert --repair pve/thinpool
Attempting repair of thin pool pve/thinpool
Thin pool pve/thinpool repaired

Qué significa: Aumentaste la capacidad de metadatos y reparaste/actualizaste las estructuras del thin pool. Dependiendo de tu entorno, puede que no necesites --repair salvo que el pool lo reclame, pero redimensionar metadata es una válvula estándar para aliviar presión.

Decisión: Si no tienes extensiones libres en el VG, detente aquí y planea expansión de almacenamiento. Extender metadata sin espacio libre no es un truco inteligente; es cómo conviertes advertencias en tiempo de inactividad.

Tarea 25: Valida el inventario de Proxmox tras cambios manuales en LVM

cr0x@server:~$ pvesm list local-lvm | grep -E 'vm-999|oldsnap' || true

Qué significa: Ninguna salida significa que Proxmox no lo ve. Si aún aparece, vuelve a escanear o puede que tengas una percepción de caché de almacenamiento obsoleta.

Decisión: Prefiere que Proxmox sea el actor para eliminar. Si debes hacer eliminaciones manuales en LVM, sigue con verificación de inventario y limpieza de configuración.

Broma #2: LVM-thin es como un cajón de trastos: todo cabe hasta que necesitas encontrar una cosa específica y está reteniendo otras tres cosas como rehenes.

Tres mini-historias corporativas (cómo falla en la práctica)

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

Una empresa mediana operaba un clúster Proxmox para servicios internos: runners de build, algunas apps legacy y un puñado de VMs “temporales” que de alguna manera sobrevivieron a tres reorganizaciones. Se usaban instantáneas con frecuencia antes de las ventanas de parcheo. El backend de almacenamiento era LVM-thin en SSDs rápidos, porque “es simple y local”.

Durante una ventana rutinaria de actualización de kernel, un ingeniero asumió que eliminar una instantánea es siempre una operación de metadatos y por tanto básicamente instantánea. Programaron eliminaciones de docenas de instantáneas antiguas en múltiples VMs mientras también se ejecutaban backups en modo snapshot. El sistema no falló inmediatamente; simplemente se volvió lento. Muy lento.

La metadata del thin pool subió hasta los altos 90. LVM empezó a lanzar advertencias, luego el thin pool pasó a solo lectura para protegerse. Ese fue el momento en que “eliminar instantáneas para liberar espacio” dejó de ser una opción, porque el acto mismo de liberar espacio requería escrituras de metadatos.

La caída no fue dramática en forma de explosiones: solo una extensión de la incapacidad de escribir: las VMs se colgaban en I/O de disco, servicios fallaban por timeout y cada dashboard se iluminó como si la red estuviera fallando. La causa raíz era el almacenamiento, pero parecía todo lo demás.

La solución fue aburrida y dolorosa: detener trabajos intensivos en instantáneas, apagar VMs no críticas para reducir el churn, extender metadata y luego podar instantáneas con cuidado y en orden controlado. La lección quedó: la eliminación de instantáneas puede ser la I/O más pesada que hagas en la semana, dependiendo de la presión de metadatos y de cuántas operaciones concurrentes permitas.

Mini-historia 2: La optimización que se volvió en contra

Otra organización quería backups más rápidos. Ajustaron su pipeline de backups para ejecutar más VMs en paralelo, aún en modo snapshot, porque reducía el downtime de los invitados. Alguien también activó una programación agresiva para que los backups terminaran antes del horario laboral. Funcionó bien unas semanas.

Luego empezó a “fallar aleatoriamente”: a veces las instantáneas no se eliminaban, a veces el uso del thin pool no bajaba, a veces los LVs permanecían “ocupados” mucho después de que el task de backup había terminado. La gente sospechó bugs de Proxmox, luego del kernel, luego “quizá firmware del SSD”. El tour habitual.

El problema real era un acoplamiento que no modelaron: los backups en paralelo aumentaron la vida y el número de dispositivos de instantánea mapeados a la vez. Eso incrementó conteos abiertos y el churn de metadatos. Cuando el uso de metadatos subió, las operaciones se hicieron más lentas, lo que alargó la ventana de backup, lo que creó más solapamiento, lo que generó más dispositivos abiertos. Un bucle de retroalimentación con un bonito corte corporativo.

Se “optimizaron” a un sistema donde la limpieza no podía seguir el ritmo de la creación. La parte que se volvió en contra no fue que la paralelización sea mala; fue que añadieron paralelismo sin guardarraíles vinculados a la salud del thin pool. La solución fue limitar la concurrencia según el porcentaje de metadatos y escalonar las operaciones de instantánea. Los backups quedaron un poco más largos, pero el clúster dejó de jugar a la ruleta del almacenamiento.

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

Un entorno regulado (mucho papeleo, mucho control de cambios) tenía un clúster Proxmox que no era el más rápido ni el más nuevo, pero sí estable. Su práctica de almacenamiento era dolorosamente conservadora: limitar el número de instantáneas por VM, imponer TTL en instantáneas “temporales” y ejecutar una auditoría semanal que comparaba el inventario de Proxmox contra LVM.

Una semana, la auditoría marcó un puñado de LVs que no existían en ninguna configuración de VM. Nadie se puso en pánico. Hicieron lo que decía el runbook: verificar conteos abiertos, comprobar tareas de replicación/backup, confirmar relaciones de origen, luego programar la eliminación en la siguiente ventana.

Dos días después, un nodo falló por un problema de hardware no relacionado. Durante la recuperación descubrieron que los LVs huérfanos provenían de un intento de migración fallido anteriormente. Si esos LVs hubieran permanecido, habrían empujado los metadatos cerca del borde durante la ráfaga de escritura de la recuperación. En cambio, había margen de metadatos y la recuperación siguió siendo aburrida. Aburrido es el mayor cumplido en operaciones.

La práctica salvadora no fue genialidad. Fue conciliación regular y límites disciplinados. Su sistema de instantáneas no era “más fiable” por un sistema de ficheros sofisticado; era fiable porque trataban el estado del almacenamiento como estado financiero: consílialo, no lo asumas.

Listas de verificación / plan paso a paso: limpieza segura de restos LVM-thin

Aquí está el plan que le daría a un on-call que necesita arreglar esto sin improvisar. El objetivo: eliminar instantáneas atascadas y LVs huérfanos sin causar pérdida accidental de datos ni convertir el thin pool en solo lectura.

Checklist A: Estabiliza al paciente

Congela la creación de nuevas instantáneas. Pausa trabajos de backup y cualquier automatización que cree instantáneas.
Comprueba el porcentaje de metadatos del thin pool. Si está muy alto, trata cada operación como más arriesgada y lenta.
Identifica si las VM(s) pueden pararse. Si puedes pararlas, resolverás condiciones “ocupadas” más rápido y de forma más segura.
Confirma que no hay ya un fallo de almacenamiento en curso. Si el pool está solo lectura o reporta errores, detente y pasa a modo incidente.

Checklist B: Prefiere eliminación nativa de Proxmox primero

Lista instantáneas con qm listsnapshot <vmid>.
Prueba la eliminación con qm delsnapshot.
Si falla, lee el log de la tarea y captura el nombre exacto del LV y el mensaje de error.
Si dice “busy”, encuentra los mantenedores abiertos y quita al mantenedor, no al LV.

Checklist C: Cuando el estado es inconsistente, reconcilia antes de eliminar

Lista volúmenes LVM para el ID de VM usando lvs.
Busca en configs de Proxmox referencias a LVs candidatos.
Comprueba relaciones snapshot/origin y conteo abierto.
Solo entonces usa pvesm free o lvremove.

Checklist D: Orden de operaciones para limpieza manual (el valor predeterminado seguro)

Para la VM si es posible (o al menos detén tareas de backup/replicación).
Elimina instantáneas primero (LVs thin de instantánea que tienen un origen).
Elimina LVs verdaderamente no usados/huérfanos después.
Vuelve a comprobar los metadatos del thin pool. Si siguen altos, considera extender la metadata o programar una poda más completa.
Vuelve a poner la VM en marcha y realiza una comprobación rápida de integridad a nivel de invitado si hiciste algo invasivo.

Checklist E: Si los metadatos del thin pool están críticamente altos

Detén el churn de instantáneas (backups, programaciones de snapshot, migraciones que hagan snapshot).
Libera victorias fáciles: elimina instantáneas obviamente antiguas en VMs no críticas primero.
Si tienes extensiones libres, amplía metadata (thinpool_tmeta).
Solo entonces intenta limpiezas más pesadas como eliminaciones masivas de instantáneas.

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

1) “La eliminación de instantánea se cuelga para siempre”

Síntoma: La tarea de Proxmox se ejecuta durante mucho tiempo; el almacenamiento permanece ocupado; eventualmente timeout.
Causa raíz: Presión de metadatos del thin pool y/o actividad concurrente intensa de instantáneas; la eliminación está haciendo trabajo real.
Solución: Reduce concurrencia, pausa backups, comprueba % de metadatos. Si es alto, extiende metadata y poda instantáneas en lotes más pequeños.

2) “TASK ERROR: contains a filesystem in use” o “device busy”

Síntoma: lvremove falla; Proxmox informa volumen ocupado.
Causa raíz: qemu o herramientas de backup todavía mantienen abierto el dispositivo dm.
Solución: Usa lsof/dmsetup info para identificar mantenedores; detén la tarea o la VM; reintenta la eliminación nativa de Proxmox.

3) “Instantánea no listada en UI, pero el espacio sigue usado”

Síntoma: No hay instantáneas en qm listsnapshot, pero el thin pool sigue lleno; hay LVs en lvs.
Causa raíz: LVs thin huérfanos debido a fallos parciales (migración, backup, crash a mitad de eliminación).
Solución: Reconcilia: escanea LVM por LVs que empiecen por vm-, busca en configs referencias, comprueba conteo abierto y luego elimina vía pvesm free o lvremove.

4) “No puedo crear instantáneas más”

Síntoma: Fallan las creaciones de instantáneas; errores sobre thin pool o espacio insuficiente.
Causa raíz: Metadata del thin pool llena (más común que quedarse sin datos en entornos con muchas instantáneas).
Solución: Extiende thinpool_tmeta si es posible; poda instantáneas; aplica límites por VM.

5) “Proxmox muestra discos ‘unused’ para siempre”

Síntoma: La configuración de la VM acumula entradas unused0, unused1; el almacenamiento nunca se libera.
Causa raíz: Desacoplar sin eliminar; valores predeterminados cautelosos; u operadores evitando acciones destructivas.
Solución: Audita con qm unused, confirma que los discos no son necesarios, luego elimina referencias de configuración y libera volúmenes vía pvesm free.

6) “Después de lvremove manual, Proxmox aún piensa que el volumen existe”

Síntoma: La interfaz muestra un volumen fantasma; las operaciones fallan con ‘volume does not exist’ o desajustes similares.
Causa raíz: Permanecen referencias de configuración (unusedX o entradas de disco), o la caché de inventario de Proxmox no se actualizó.
Solución: Elimina referencias en la configuración de la VM vía qm set --delete; verifica con pvesm list.

Preguntas frecuentes

1) ¿Es seguro eliminar instantáneas LVM-thin mientras la VM está en ejecución?

A veces, sí—cuando Proxmox creó la instantánea y la elimina en un flujo normal. Si el LV está “ocupado”, la respuesta segura se convierte en “detén la VM o la tarea que lo mantiene”. No luches contra dispositivos abiertos.

2) ¿Por qué los metadatos del thin pool se llenan más rápido que los datos?

Las instantáneas y cambios frecuentes de bloques generan muchas actualizaciones de mapeo. Los metadatos rastrean esos mapeos. Un pequeño LV de metadatos puede convertirse en el factor limitante mucho antes de que te quedes sin espacio de datos.

3) Si `qm listsnapshot` está vacío, ¿puede aún haber instantáneas?

Sí. Proxmox rastrea instantáneas en el estado de configuración; LVM rastrea volúmenes thin de instantánea. Si una eliminación o migración falló parcialmente, LVM puede retener LVs de instantánea que Proxmox ya no referencia.

4) ¿Cuál es la forma más segura de eliminar un LV thin LVM huérfano?

Primero demuestra que no está referenciado: busca en configs de Proxmox, comprueba cadenas de origen, confirma que el conteo abierto es cero. Luego elimina vía pvesm free si Proxmox lo conoce, de lo contrario lvremove.

5) ¿Puedo simplemente reiniciar el nodo para limpiar “device busy”?

Un reinicio a menudo limpiará conteos abiertos, sí. También suele acabar con tu ventana de mantenimiento y convertirla en un incidente. Reinicia solo cuando entiendas quién mantiene el dispositivo y puedas tolerar el impacto.

6) ¿Por qué no bajó el uso del thin pool después de eliminar instantáneas?

La recuperación de espacio puede demorarse por el comportamiento de discard, el control interno del thin pool y escrituras en curso. Además, si la instantánea retenía bloques únicos que todavía están referenciados en otro lugar, no recuperarás tanto espacio como esperabas.

7) ¿Cuál es la diferencia entre “unused disk” y “resto de instantánea” en términos de Proxmox?

“Unused disk” es una referencia de configuración de Proxmox a un volumen no adjunto a la VM. Un “resto de instantánea” suele ser un LV LVM que existe sin un registro de instantánea correspondiente en Proxmox (o viceversa).

8) ¿Debería extender la metadata del thin pool o simplemente eliminar más instantáneas?

Si los metadatos están cerca del borde y tienes extensiones libres, extender metadata compra seguridad y tiempo. Aún así elimina instantáneas: la extensión no es una dieta, es un cinturón más grande.

9) ¿Cómo evito que esto vuelva a ocurrir?

Limita el número y la duración de instantáneas, fija la concurrencia de backups según el % de metadatos del thin, y ejecuta conciliaciones regulares entre configuraciones de Proxmox y volúmenes LVM. Además: deja de permitir que instantáneas “temporales” se conviertan en inquilinos permanentes.

Conclusión: siguientes pasos para mantenerte a salvo

Cuando las instantáneas de Proxmox no se eliminan, el problema rara vez es “un botón roto”. Casi siempre es una de tres cosas: un lock/tarea obsoleta, un thin pool con presión de metadatos, o un dispositivo abierto que LVM correctamente se niega a destruir.

Haz el diagnóstico rápido en orden. Usa las eliminaciones nativas de Proxmox cuando sea posible. Cuando debas ir manual, reconcilia el estado primero, verifica conteos abiertos y elimina en el orden correcto. Luego hazte el favor de prevenir: aplica TTLs a las instantáneas, limita la concurrencia y monitoriza los metadatos del thin como un SLO de primera clase.