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 <[email protected]> --- 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
