[pve-devel][storage] Lack of deactivate_volume call after cloning from a snapshot
Andrei Perapiolkin
andrei.perepiolkin at open-e.com
Wed Oct 1 00:39:32 CEST 2025
Hi,
'deactivate_volume' in the storage plugin is not called after cloning
completes if the clone is initiated from the Proxmox web UI and both VMs
are on the same host.
I’ve created a bug report: https://bugzilla.proxmox.com/show_bug.cgi?id=6879
In my understanding, the problem is related to:
/method({ name => 'clone_vm', path => '{vmid}/clone', ...
/
Located in PVE/API2/Qemu.pm around 1459 - 4568
In this API method, deactivation calls are triggered only when the
$target parameter is provided.
if ($target) {
if (!$running) {
# always deactivate volumes - avoids that LVM
LVs are active on several nodes
eval {
PVE::Storage::deactivate_volumes($storecfg, $vollist, $snapname);
};
# but only warn when that fails (e.g., parallel
clones keeping them active)
log_warn($@) if $@;
}
PVE::Storage::deactivate_volumes($storecfg,
$newvollist);
my $newconffile =
PVE::QemuConfig->config_file($newid, $target);
die "Failed to move config to node '$target' -
rename failed: $!\n"
if !rename($conffile, $newconffile);
}
https://github.com/proxmox/qemu-server/blob/31d6f5f63bd6edb6c43de3e0213d38199c350cd4/src/PVE/API2/Qemu.pm#L4533C1-L4547C18
It seems that web UI, for cloning on the same node, does not provide
'$target' and as a result no deactivation being triggered volume
snapshot and target volume.
Is it expected behavior?
Will it be OK to move 'deactivate' section outside of the $target check?
Best regards,
Andrei Perepiolkin
More information about the pve-devel
mailing list