qemu-img zeroinit on LVM thin volumes doesn’t actually zero the data on Proxmox. The command reports success but leaves old data intact. That’s a bug, not expected behavior, and the workaround is to use blkdiscard or dd instead.
Reproduce it
Create a thin volume on Proxmox, write some data to it, then run qemu-img zeroinit. Check the underlying blocks and you’ll see the old data is still there. The command exits 0, no errors, but nothing was zeroed.
lvcreate -V 1G --thinpool data -n testvol
mkfs.ext4 /dev/data/testvol
mount /dev/data/testvol /mnt
echo "secret" > /mnt/file
umount /mnt
qemu-img zeroinit /dev/data/testvol
# read back the raw device and search for 'secret'
strings /dev/data/testvol | grep secretIf the zeroinit worked, that grep would return nothing. On LVM thin it returns the string. The bug is that zeroinit issues a write zeroes command that the thin target ignores or mishandles, so the operation is a no-op while reporting success.
Why it matters
If you’re using zeroinit to wipe a disk before decommissioning or reusing it, you think the data is gone. It isn’t. That’s a security problem, not just a cosmetic one. Same thing happens with qcow2 files on thin volumes.
The workaround
Use blkdiscard if the volume supports discard, or dd with /dev/zero. blkdiscard is faster because it just discards blocks, but it only works if the underlying storage supports discard. dd always works but is slower.
# Option 1: blkdiscard (fast, requires discard support)
blkdiscard /dev/data/testvol
# Option 2: dd (slow, always works)
dd if=/dev/zero of=/dev/data/testvol bs=1M status=progressAfter either one, the strings command won’t find the old data. I’d use blkdiscard first and fall back to dd if it fails. The LVM thin pool on Proxmox is backed by local storage that usually supports discard, but not always.
Is it a bug?
Yes. qemu-img zeroinit should either zero the data or report an error. Silently doing nothing is the worst outcome. The Proxmox forum has threads about this but no maintainer confirmation. It’s been around for a while and still isn’t fixed. Check your version with qemu-img --version; I’ve seen it on qemu 7.x and 8.x.
If you’re wiping disks before deleting VMs, don’t trust zeroinit on LVM. Use blkdiscard or dd. And if you’re just trying to reclaim space, use fstrim on the mounted filesystem instead.
Related: Need to delete local-lvm and reuse the size in Proxmox covers the LVM side of things.
