LVM Snapshot-as-Volume-Chain: Newly created qcow2 image reuses old guest data after VM deletion

K

krisshurley

New Member
Aug 10, 2026
3
0
1
Hi,

I believe I have found an issue with LVM storage using snapshot-as-volume-chain=1.

I can reproduce it consistently on a fully updated Proxmox VE 9.2 installation on multiple cluster nodes.

Environment​

Proxmox VE 9.2.10
qemu-server 9.2.5
pve-qemu-kvm 11.0.3-2
lvm2 2.03.31
Storage configuration:

lvm: rtnsan03_vdisk01_thick
vgname vg_rtnsan03_vdisk01
content images
saferemove 0
shared 1
snapshot-as-volume-chain 1
The storage is a shared Fibre Channel LUN from an IBM FlashSystem 5600 presented as a normal LVM volume group.

Steps to reproduce​

  1. Create a VM with a qcow2 disk on this storage.
  2. Install Ubuntu Server.
  3. Shut down the VM.
  4. Delete the VM using Remove → Purge.
  5. Create a new VM using the same VMID and storage.
  6. Boot the new VM.

Expected result​

The newly created qcow2 image should be empty and boot directly into the Ubuntu installer.

Actual result​

The VM boots directly into the previous Ubuntu installation.

No installer is shown.

The complete previous operating system is still present.

What I have verified​

The logical volume is recreated​

lvs -o lv_name,devices
shows a newly created LV.

The qcow2 image is valid​

qemu-img info
reports:

file format: qcow2
compat: 1.1

No corruption is detected​

qemu-img check
returns:

No errors were found.

The qcow2 image is not empty​

Running

qemu-img map --output=json \
/dev/vg_rtnsan03_vdisk01/vm-100-disk-0.qcow2
shows the entire virtual disk allocated (present=true) instead of mostly sparse.

Converting the qcow2 image to RAW​

I converted the qcow2 image to a raw image:

qemu-img convert \
-O raw \
/dev/vg_rtnsan03_vdisk01/vm-100-disk-0.qcow2 \
test.raw
Inspecting the resulting raw image with fdisk shows the previous partition table:

GPT

Partition 1 BIOS boot
Partition 2 ext4
Partition 3 LVM
I then mounted the LVM from inside the Ubuntu installer environment:

mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt/test
and verified:

cat /mnt/test/etc/hostname
which returned:

ubuntu01
This is the hostname from the VM that had already been deleted.

Summary​

The recreated qcow2 image appears to reference the complete contents of the previously deleted guest instead of starting as a new empty image.

This is not just leftover filesystem signatures (wipefs-style metadata). The previous guest is completely readable:

  • GPT partition table
  • ext4 filesystem
  • LVM metadata
  • Complete Ubuntu installation
  • Previous hostname
  • VM boots successfully into the old operating system
Since qemu-img check reports no corruption and qemu-img convert produces a fully bootable raw image containing the previous guest, it appears that the newly created qcow2 image is referencing existing guest data rather than being initialized as an empty image.

Has anyone seen this before with snapshot-as-volume-chain?

Is this expected behaviour, or does this look like a bug?
 
Last edited:
LnxBil said:
Another AI slop post .... there will be a time when most people just TL;DR ...


Have you checked the Wipe removed volumes checkbox?
Click to expand...
Yes, I have tested both configurations.

With Wipe removed volumes enabled, I cannot reproduce the issue.

With it disabled (the default configuration), I can reproduce it consistently.

My expectation is that a newly created qcow2 image should not expose the complete contents of a previously deleted VM, regardless of whether the previous LV was zeroed before removal.

I therefore wanted to understand whether this is expected behaviour with snapshot-as-volume-chain, or whether this is a bug.
 
Welcome to the Forum, @krisshurley

I think this is the similar situation like mentioned e.g. there:
T

Thread 'LVM Storage on SAN, new VM and Disk show data from a previous deleted system/disk'

Hi,

today created a new VM to evaluate AlmaLinux 10.1, when i try to boot it, it booted an old Ubuntu System that was deleted a few days ago. This is LVM on a FC SAN with Snapshots as Volume Chains enabled.

It makes kinda sense if lvm is allocating something in thick mode but does itself nothing with data in that range. I think this is dangerous depending on who has access to a VM, an auto provision VM may accidently boot from disk and not ISO because there is a valid signature and parition. Is this expected with storage on LVM?

I think this may have an affect on Backup, if there is a...

The solution is probably using an additional option in the configuration: saferemove
optionally with supplemental options. Described at https://pve.proxmox.com/wiki/Storage:_LVM
 
krisshurley said:
Yes, I have tested both configurations.

With Wipe removed volumes enabled, I cannot reproduce the issue.

With it disabled (the default configuration), I can reproduce it consistently.

My expectation is that a newly created qcow2 image should not expose the complete contents of a previously deleted VM, regardless of whether the previous LV was zeroed before removal.

I therefore wanted to understand whether this is expected behaviour with snapshot-as-volume-chain, or whether this is a bug.
Click to expand...
Of course it's expect. Why would there be an option to wipe the volume if you would have the same without wiping it?
 
Onslow said:
Welcome to the Forum, @krisshurley

I think this is the similar situation like mentioned e.g. there:
T

Thread 'LVM Storage on SAN, new VM and Disk show data from a previous deleted system/disk'

Hi,

today created a new VM to evaluate AlmaLinux 10.1, when i try to boot it, it booted an old Ubuntu System that was deleted a few days ago. This is LVM on a FC SAN with Snapshots as Volume Chains enabled.

It makes kinda sense if lvm is allocating something in thick mode but does itself nothing with data in that range. I think this is dangerous depending on who has access to a VM, an auto provision VM may accidently boot from disk and not ISO because there is a valid signature and parition. Is this expected with storage on LVM?

I think this may have an affect on Backup, if there is a...

The solution is probably using an additional option in the configuration: saferemove
optionally with supplemental options. Described at https://pve.proxmox.com/wiki/Storage:_LVM
Click to expand...
Thanks.

I have read that thread, and it definitely helped me understand why enabling saferemove prevents the issue.

I may still be misunderstanding how snapshot-as-volume-chain is intended to work, which is why I'm asking.

During my testing I verified that:

  • qemu-img check reports no errors.
  • qemu-img convert successfully converts the qcow2 image to a raw image.
  • The converted raw image still contains the complete GPT partition table, LVM metadata, ext4 filesystem, and the previous Ubuntu installation.
  • Mounting the filesystem shows the hostname from the previously deleted VM.
So my question isn't whether saferemove fixes the problem—it clearly does.

I'm mainly trying to understand whether this behaviour is considered the expected design when using snapshot-as-volume-chain with saferemove disabled, or whether a newly created qcow2 image is expected to present an empty logical view even though the underlying LV still contains old blocks.

I'm not trying to argue that this is necessarily a bug—I'm simply trying to understand the intended behaviour.

(And yes, I used AI to help write this post, but all commands, tests and observations are from my own lab.)
 
You must log in or register to reply here.
Top Bottom
Back