Thin Pool `vg_hdd-data-tpool` stuck with open count 1, preventing volume deactivation and reboot

[Artsiom]

Hello Proxmox community,

I’m experiencing a problem with one of my LVM thin pools (`vg_hdd-data-tpool`) on my Proxmox server. Despite stopping all VMs and containers using the `vg_hdd` volume group and unmounting all related logical volumes, the thin pool device remains active with an open count of 1. This prevents me from deactivating the volume and complicates server reboot or maintenance.

### Environment:

* Proxmox VE version: 8.4.0
* LVM thin pool: vg_hdd-data-tpool
* Volume group: vg_hdd
* Storage device: /dev/sdb

### What I have done:

1. Stopped all VMs and containers:

* Verified no running QEMU/KVM processes (`ps aux | grep kvm`)
* Verified no running LXC containers (`pct list` shows stopped)

2. Checked device usage:

* `lsof /dev/mapper/vg_hdd-data-tpool` shows no processes using it
* `fuser -v /dev/mapper/vg_hdd-data-tpool` shows no active processes

3. Checked dmsetup info:

```
dmsetup info vg_hdd-data-tpool
Name: vg_hdd-data-tpool
State: ACTIVE
Open count: 1
```

4. Attempted to deactivate logical volumes:

* `lvchange -an vg_hdd/data` returns error: "Attempted to decrement suspended device counter below zero."
* `lvchange -an vg_hdd/data-tpool` returns: "Failed to find logical volume"

5. Tried to stop `dmeventd` daemon (PID 930), but the thin pool remains active.

6. Rebooted the server, but the thin pool still shows an open count of 1 on boot.

7. Thin pool metadata shows errors suggesting to run `thin_check` with `--repair`, but:

* `thin_check /dev/vg_hdd/data` returns "Couldn't stat path"
* The block device path might be different or not accessible in normal mode.

### Additional info:

* No multipath configuration is in use.
* `lvs -a -o +devices` shows the pool is active and linked to the correct devices.
* No snapshots or dependent volumes appear to be active.
* No other processes (besides kernel workers and system daemons) seem to be holding the device.

### Problem summary:

The thin pool device remains active with an open count of 1 despite no visible usage, preventing logical volume deactivation or clean unmount. This blocks maintenance operations and complicates reboots.

### Request:

Could anyone advise how to safely identify what is holding this open count?
Is there a recommended procedure to force deactivate or repair the thin pool without risking data loss?
Would booting into rescue mode and running `thin_check --repair` be the safest next step?

Any insights or suggestions to resolve this stuck open count issue on the thin pool would be greatly appreciated.

Thank you in advance!

 

[niall.keller]

Anyone?

 

[bbgeek17]

LVM is not my area of expertise, but here are a few things to try and report back:

1. An open count of 1 on -tpool is normal while the pool is active. It's the internal pool device, held open by the thin LVs and by dmeventd monitoring. lvchange -an vg_hdd/data-tpool fails because -tpool is a hidden internal LV. Deactivate via vg_hdd/data or the whole VG instead.

2. The important message here is "decrement suspended device counter below zero." That usually means a device is stuck suspended after an interrupted LVM operation. Check:

dmsetup info -c | grep vg_hdd
dmsetup ls --tree

If the Stat column shows s, run dmsetup resume <name> and retry.

3. Try to disable monitoring :

vgchange --monitor n vg_hdd
vgchange -an vg_hdd

Back up first (vgcfgbackup vg_hdd and any critical VM disks). Rescue path only makes sense if the metadata turns out to be damaged, and we dont know this for sure.

If it's still stuck, please post the output of dmsetup info -c, lvs -a -o+lv_active,lv_device_open vg_hdd, and journalctl -b | grep -i thin.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox