From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 88CF31FF141 for ; Tue, 30 Jun 2026 16:04:48 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id F28AB21422; Tue, 30 Jun 2026 16:04:46 +0200 (CEST) Message-ID: Date: Tue, 30 Jun 2026 16:04:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH qemu-server v9 07/10] adapt linked clone check to not die if an error occurs during check To: =?UTF-8?Q?Michael_K=C3=B6ppl?= , pve-devel@lists.proxmox.com References: <20260629140439.184878-1-m.koeppl@proxmox.com> <20260629140439.184878-8-m.koeppl@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260629140439.184878-8-m.koeppl@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1782828270800 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: IAKH7XTWXTN3TESPJYMAN4FAZYCGENDN X-Message-ID-Hash: IAKH7XTWXTN3TESPJYMAN4FAZYCGENDN 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: A prefix for the commit title like "destroy vm:" would be nice. Same goes for patch 6/10 where I only noticed it now. Am 29.06.26 um 4:05 PM schrieb Michael Köppl: > Align error handling behavior when checking for linked clones with the > rest of destroy_vm's error handling approach. In case an error occurred, > a warning is printed and the execution continues, since: > > 1. The same validation occurs later in the process > 2. The VM removal will still be blocked if the volume has linked clones > > Originally-by: Stefan Hrdlicka > [ MK: log_warn if check fails instead of ignoring > resolve style nits ] > Signed-off-by: Michael Köppl > --- > src/PVE/QemuServer.pm | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm > index cdf66e89..ed5bca0c 100644 > --- a/src/PVE/QemuServer.pm > +++ b/src/PVE/QemuServer.pm > @@ -1838,8 +1838,10 @@ sub destroy_vm { > my $volid = $drive->{file}; > return if !$volid || $volid =~ m|^/|; > > - die "base volume '$volid' is still in use by linked cloned\n" > - if PVE::Storage::volume_is_base_and_used($storecfg, $volid); > + my $result = eval { PVE::Storage::volume_is_base_and_used($storecfg, $volid) }; > + log_warn("failed to check if volume '$volid' is used by linked clones: $@") > + if $@; Same as for patch 6/10, a code comment would be nice here. > + die "base volume '$volid' is still in use by linked cloned\n" if $result; > > }, > );