**Sequence of events (VM 344):** 1. **Apr 7, 15:50** — User deletes b4patch snapshots while LV `Vol_01` is full. QEMU fails to flush persistent bitmaps (`No space left on device`), but the Proxmox task `qmdelsnapshot` returns `OK`. Error is silently lost between QEMU and the task log. * **Apr 8, 07:01:48** — `qemu-img info` reports two valid `VeeamTmp_*` bitmaps still present. * **Apr 8, 07:01:49** — issue `block-dirty-bitmap-remove` over QMP. QMP returns `{}` (success), while QEMU internally logs `qcow2_free_clusters failed: Invalid argument` ×6. * **Apr 8, 07:01:55** — Disk no longer opens; all subsequent snapshot/migrate/vzdump tasks fail. Root cause — two defects in block/qcow2-bitmap.c:   **Bug 1:** qcow2_co_remove_persistent_dirty_bitmap ignores the return value of free_bitmap_clusters. When it fails with EINVAL, QMP still reports success, so callers have no way to detect inconsistent state. **Bug 2:** `bitmap_list_store` does not zero the cluster tail after writing the bitmap directory. On thick LVM (no zero-on-allocation), the tail contains stale data. If a prior ENOSPC left the `bitmap_directory_size` extension-header field inconsistent, `qemu-img` parses into stale bytes and hits an entry with `name_size=0`, producing the unrecoverable `Bitmap ''` error. Reproduced on a test hypervisor: LV pre-filled with `0xAA`, two bitmaps added, one removed — raw cluster dump confirmed `0xAA` bytes beyond `dir_size`. **Proposed fix:**   Zero the cluster tail after writing in `bitmap_list_store`; treat `free_bitmap_clusters` failure as fatal and roll back the header update.