Re: [pve-devel] [PATCH pve-storage 08/10] qcow2: add external snapshot support - DERUMIER, Alexandre via pve-devel

From: "DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
	"f.gruenbichler@proxmox.com" <f.gruenbichler@proxmox.com>
Cc: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [PATCH pve-storage 08/10] qcow2: add external snapshot support
Date: Mon, 7 Jul 2025 10:18:28 +0000	[thread overview]
Message-ID: <mailman.1065.1751883518.395.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <1276950999.2693.1751876235796@webmail.proxmox.com>

[-- Attachment #1: Type: message/rfc822, Size: 16707 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "f.gruenbichler@proxmox.com" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-storage 08/10] qcow2: add external snapshot support
Date: Mon, 7 Jul 2025 10:18:28 +0000
Message-ID: <c671fe82a7cdab90a3691115a7132d0a35ae79b7.camel@groupe-cyllene.com>

> 
> or maybe use something else than volume_snapshot_info here, simply
> glob
> all the vm disk && snap files and delete them in random order, as we
> want to delete it anyway.

yes, this is exactly what I meant with tricky ;)

>>if we start deleting snapshots from the "first"/root one, then it's
>>easier to retry deletion after a partial deletion - but the image
>>still
>>"looks" like a valid one at first glance (although it is of course
>>unusable as soon as any snapshot is missing!)

ok, I see 

>>if we start deleting with the image file, then it is immediately
>>clear
>>that there is no more image to be used - but retrying a partial
>>deletion
>>is impossible via the PVE API, you need to do it manually.
>>
>>I just tried, and this would need more work if we want to support the
>>"retry partial deletion" approach - because:
>>
>>root.qcow2 <- snap.qcow2 <- current.qcow2
>>
>>delete root.qcow2
>>
>>$ qemu-img info --output json --backing-chain -f qcow2 current.qcow2
>>qemu-img: Could not open 'root.qcow2': Could not open 'root.qcow2':
>>No such file or directory
>>
>>so we'd need to actually query image by image and detect when the
>>chain
>>is broken, if we want to support that which might not be worth it, if
>>the snapshot deletion log contains the information about which
>>snapshot
>>volumes are leftover and need to be manually cleaned?

yes, I think that it could be manually cleaned, no problem.
I'll revert the delete starting with current.
> 
> what about lvm ? (I think it should be great to have same scheme for
> both, but lvm have also reserved characters like @)

>>the naming scheme is already different:

>><VMID>/<anything except slash and spaces>.<fmt> (dir)
>>
>>vs
>>
>>vm-<VMID>-<anything except spaces>[.<qcow2>] (LVM)

>>the LVM one is in practicate limited further by what is allowed in LV
>>names, like you said. but for LVM it's fine as it is because of the
>>`vm-` prefix, we can add a second namespace besides it with `snap-`
>>without the risk of collisions. or we could switch to make it uniform
>>with LVM thin, which uses
>>
>>snap_<volname>_<snap>
>>
>>as snapshot LV name.. that would make it (for example)
>>
>>snap_vm-100-disk-1.qcow2_foobar
>>
>>for a snapshot nameed "foobar" of the volume "vm-100-disk-1.qcow2"
>>
>>
>>for the DirPlugin we need to add another level for the snapshots
>>on-disk, else we cannot differentiate between weirdly-named image
>>files and snapshot files..
>>
>>so we could add a directory "snapshots" and put all the snapshot
>>files in there. since snapshots are never references a volume ID,
>>this just affects the on disk structure, not the volume ID format.

ok, no problem, I'll do it like this.

Do you want the a snapshot sub directory like ?
/var/lib/vz/images/<vmid>/snapshots/ 

or a global snapshots like

/var/lib/vz/snapshots/<vmid>/

?

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel