[PATCH storage 1/2] fix #7280: lvm plugin: rename: activate qcow2 volume to read snapshot info

[Fiona Ebner <f.ebner@proxmox.com>]

Other callers of volume_snapshot_info() already do this. For other
storages and formats, activation is not necessary to rename it, so the
activation is only added here, rather than in the qemu-server, and, for
consistency, container API endpoints.

There is no need for deactivation after the rename operation. In fact,
in case of reassign to a running target VM with SCSI or VirtIO block,
the renamed disk is even hotplugged, so deactivation would be wrong.

Note that the order of $scfg and $storeid really is switched when
comparing volume_snapshot_info() and activate_volume().

Technically, the check for snapshots would not be needed, as
reassigning a volume referenced in a snapshot is already prohibited by
the guest API endpoints. But additional checks on the storage layer
don't hurt and there might be other users of rename_volume() in the
future.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 src/PVE/Storage/LVMPlugin.pm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/PVE/Storage/LVMPlugin.pm b/src/PVE/Storage/LVMPlugin.pm
index 32a8339..f9349de 100644
--- a/src/PVE/Storage/LVMPlugin.pm
+++ b/src/PVE/Storage/LVMPlugin.pm
@@ -1439,6 +1439,7 @@ sub rename_volume {
     ) = $class->parse_volname($source_volname);
 
     if ($format eq 'qcow2') {
+        $class->activate_volume($storeid, $scfg, $source_volname);
         my $snapshots = $class->volume_snapshot_info($scfg, $storeid, $source_volname);
         die "we can't rename volume if external snapshot exists" if $snapshots->{current}->{parent};
     }
-- 
2.47.3