[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