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 CAF8E1FF142 for ; Fri, 03 Jul 2026 11:31:45 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C6B8C2138E; Fri, 03 Jul 2026 11:31:44 +0200 (CEST) Message-ID: <9aee436a-69a0-41ed-a6c8-46107aded293@proxmox.com> Date: Fri, 3 Jul 2026 11:31:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH qemu-server 2/3] fix #7743: api: disk import: avoid locking twice when importing from OVA or same VM To: Fiona Ebner , pve-devel@lists.proxmox.com References: <20260629124625.115457-1-f.ebner@proxmox.com> <20260629124625.115457-3-f.ebner@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260629124625.115457-3-f.ebner@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783071061995 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.066 Adjusted score from AWL reputation of From: address 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: LTIALXBDPQGE3TZ5FOVG3OBDVMYWYNQU X-Message-ID-Hash: LTIALXBDPQGE3TZ5FOVG3OBDVMYWYNQU X-MailFrom: d.csapak@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: On 6/29/26 2:46 PM, Fiona Ebner wrote: > 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 explanation makes sense, and it fixes the issue (works now for POST & PUT) but i'm somehow missing the connection here? AFAIU the reason is that in the async case we lock the config then fork and then lock again (which does not work) but in the sync case we lock and later lock again in the same process so the cached lock in PVE::Tools succeeds? IMHO the code and rationale is fine here, but i would find it good to get the actual reason why it failed + why this change impacts the POST vs PUT case. Otherwise from the commit message consider this Reviewed-by: Dominik Csapak > > Signed-off-by: Fiona Ebner > --- > 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->(); > }