From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 6F7531FF142 for ; Fri, 03 Jul 2026 13:54:44 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 6592721442; Fri, 03 Jul 2026 13:54:39 +0200 (CEST) From: Fiona Ebner To: pve-devel@lists.proxmox.com Subject: [PATCH qemu-server v2 2/3] fix #7743: api: disk import: avoid locking twice when importing from OVA or same VM Date: Fri, 3 Jul 2026 13:54:17 +0200 Message-ID: <20260703115432.108667-3-f.ebner@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260703115432.108667-1-f.ebner@proxmox.com> References: <20260703115432.108667-1-f.ebner@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783079667637 X-SPAM-LEVEL: Spam detection results: 0 DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: Z4ZCPNFXXRJYBSM36F2V3G4GQHOBKREN X-Message-ID-Hash: Z4ZCPNFXXRJYBSM36F2V3G4GQHOBKREN X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: When import_from_volid->() is called, the VM configuration of the destination VM is already locked. In case the source volume belongs to the same VM, there would be a second attempt to lock the config. In particular, this also happens when importing from OVA, because the source image is first extracted and belongs to the same VM. The reason this fixes bug #7743, is that the API call will lock before forking a worker in the POST case, making a second lock attempt from the different process fail. In the PUT case, the second lock attempt will still succeed, because the lock is cached within the process in PVE::Tools::lock_file_full(). Commit "api: update vm: fork before locking" will address this second part of the issue. Signed-off-by: Fiona Ebner Tested-by: Manuel Federanko Reviewed-by: Dominik Csapak --- src/PVE/API2/Qemu.pm | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm index e575d36b..b2a15d96 100644 --- a/src/PVE/API2/Qemu.pm +++ b/src/PVE/API2/Qemu.pm @@ -390,10 +390,13 @@ my $import_from_volid = sub { }; my $cloned; - if ($running) { - $cloned = PVE::QemuConfig->lock_config_full($src_vmid, 30, $clonefn); - } elsif ($src_vmid) { - $cloned = PVE::QemuConfig->lock_config_shared($src_vmid, 30, $clonefn); + # The config is already locked for the destination. + if ($src_vmid && $src_vmid != $dest_info->{vmid}) { + if ($running) { + $cloned = PVE::QemuConfig->lock_config_full($src_vmid, 30, $clonefn); + } else { + $cloned = PVE::QemuConfig->lock_config_shared($src_vmid, 30, $clonefn); + } } else { $cloned = $clonefn->(); } -- 2.47.3