Between destroying a VM (unlink config file) and removing it from user.cfg creating a new VM with the ID that is still in use in user.cfg was possible. VMs could go missing as a consequence.
Adding a lock solves this. This lock does not interfere with the one in vm_destroy as they are held by the same process. Signed-off-by: Dominic Jäger <d.jae...@proxmox.com> --- PVE/API2/Qemu.pm | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm index 267a08e..7dd83a9 100644 --- a/PVE/API2/Qemu.pm +++ b/PVE/API2/Qemu.pm @@ -1492,9 +1492,11 @@ __PACKAGE__->register_method({ my $upid = shift; syslog('info', "destroy VM $vmid: $upid\n"); - PVE::QemuServer::vm_destroy($storecfg, $vmid, $skiplock); - PVE::AccessControl::remove_vm_access($vmid); - PVE::Firewall::remove_vmfw_conf($vmid); + PVE::QemuConfig->lock_config($vmid, sub { + PVE::QemuServer::vm_destroy($storecfg, $vmid, $skiplock); + PVE::AccessControl::remove_vm_access($vmid); + PVE::Firewall::remove_vmfw_conf($vmid); + }); }; return $rpcenv->fork_worker('qmdestroy', $vmid, $authuser, $realcmd); -- 2.20.1 _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel