[pve-devel] [PATCH v4 qemu-server 11/11] qcow2: add external snapshot support

[Fabian Grünbichler]

> DERUMIER, Alexandre <alexandre.derumier at groupe-cyllene.com> hat am 04.04.2025 13:31 CEST geschrieben:
> Hi Fabian,
> 
> >>the first one is the renaming of a blockdev while it is used, which
> >>is currently done like this:
> >>-- "link" snapshot path to make it available under old and new name
> >>-- handle blockdev additions/reopening/backing-file updates/deletions
> >>on the qemu layer
> >>-- remove old snapshot path link
> >>-- if LVM, rename actual volume (for non-LVM, linking followed by
> >>unlinking the source is effectively a rename already)
> 
> >>I wonder whether that couldn't be made more straight-forward by doing
> >>-- rename snapshot volume/image (qemu must already have the old name
> >>open anyway and should be able to continue using it)
> >>-- do blockdev additions/reopening/backing-file updates/deletions on
> >>the qemu layer
> 
> >>or is there an issue/check in qemu somewhere that prevents this
> >>approach? if not, we could just introduce a "volume_snapshot_rename"
> >>or extend rename_volume with a snapshot parameter..
> 
> I have done tests this last 2 days, and it's working fine indeed. (I
> have done test with fio running during the snapshot rename/reopen, no
> problem).
> 
> so I'm using Storage::rename_volume now with snapshot param
> 
> 
> >>the second thing that happens is deleting a snapshot volume/path,
> >>without deleting the whole snapshot.. that one we could easily
> >>support by extending volume_snapshot_delete by extending the $running
> >>parameter (e.g., passing "2") or adding a new one to signify that all
> >>the housekeeping was already done, and just the actual snapshot
> >>volume should be deleted. this shouldn't be an issue provided all
> >>such calls are guarded by first checking that we are using external
> >>snapshots..
> 
> I have reused vdisk_free for this one, as I'm seeing a comment about
> $running deprecation in Storage.pm
> 
> # FIXME PVE 8.x remove $running parameter (needs APIAGE reset)
> sub volume_snapshot_delete {
>     my ($cfg, $volid, $snap, $running) = @_;
> 
> 
> vdisk_free have also a cluster_lock_storage, so for lvm , I think it's
> better.
> 
> (I have introduce a $snap param to vdisk_free, to only delete the
> specific snapshot, and not the whole chain)

vdisk_free is definitely wrong - you are not deleting a vdisk, just a
snapshot.. I think this might be an argument for keeping $running ;)

you can call the lock inside volume_snapshot_delete, right?