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 D9F211FF0B3 for ; Wed, 28 Oct 2026 15:00:05 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 40FFC2140D; Wed, 28 Oct 2026 15:00:02 +0100 (CET) Message-ID: Date: Wed, 28 Oct 2026 14:59:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH qemu-server v4 9/9] hotplug: remove iothread if adding drive device failed To: Dominik Csapak , pve-devel@lists.proxmox.com References: <20261023130324.451252-1-d.csapak@proxmox.com> <20261023130324.451252-10-d.csapak@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20261023130324.451252-10-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793195997746 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.336 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) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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: 3F2K3VYJFKIFNTDHJILSIWXOD6ZWSQOJ X-Message-ID-Hash: 3F2K3VYJFKIFNTDHJILSIWXOD6ZWSQOJ 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: Am 23.10.26 um 3:04 PM schrieb Dominik Csapak: > diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm > index 5be49090..95a8c6c1 100644 > --- a/src/PVE/QemuServer.pm > +++ b/src/PVE/QemuServer.pm > @@ -3913,6 +3913,8 @@ sub vm_deviceplug { Above here are more calls that could fail and leave the iothread object behind. We should expand the eval block and maybe have variables to track which delete operations to do in the error case based on how far we got. Or just attempt the delete operations always, shouldn't hurt either? > if (my $err = $@) { > eval { qemu_drivedel($vmid, $deviceid); }; > warn $@ if $@; > + eval { qemu_iothread_del($vmid, $deviceid, $device) }; > + warn $@ if $@; > die $err; > } > } elsif ($deviceid =~ m/^(virtioscsi|scsihw)(\d+)$/) { > @@ -3932,7 +3934,14 @@ sub vm_deviceplug { > } > > qemu_deviceadd($vmid, $devicefull); This call should be in the eval too. > - qemu_deviceaddverify($vmid, $deviceid); > + eval { qemu_deviceaddverify($vmid, $deviceid) }; > + if (my $err = $@) { > + if ($deviceid =~ m/^virtioscsi(\d+)$/ && $device->{iothread}) { > + eval { qemu_iothread_del($vmid, $deviceid, $device) }; > + warn $@ if $@; > + } > + die $err; > + } > } elsif ($deviceid =~ m/^(scsi)(\d+)$/) { > qemu_findorcreatescsihw($storecfg, $conf, $vmid, $device, $arch, $machine_type); > qemu_driveadd($storecfg, $vmid, $device);