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 035781FF0BC for ; Thu, 29 Oct 2026 16:27:20 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 312FB2125E; Thu, 29 Oct 2026 16:27:17 +0100 (CET) Message-ID: <5156a6ff-0cad-4589-a523-34590ca7f6f6@proxmox.com> Date: Thu, 29 Oct 2026 16:27:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH qemu-server] fix #6490: network: add bridge fdb entries when hotplugging a nic To: Gabriel Goller , =?UTF-8?Q?R=C3=A9mi_PAETA?= References: <20261013095852.2586609-1-remi.paeta@comaite.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793287630016 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.323 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: CV6GTZOS4HO23URP6CSIWYRTVYDCVZGY X-Message-ID-Hash: CV6GTZOS4HO23URP6CSIWYRTVYDCVZGY 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 CC: pve-devel@lists.proxmox.com 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 14.10.26 um 11:40 AM schrieb Gabriel Goller: > On 13.10.2026 11:58, Rémi PAETA wrote: >> [snip] >> diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm >> index 74772fdd..4c2bd334 100644 >> --- a/src/PVE/QemuServer.pm >> +++ b/src/PVE/QemuServer.pm >> @@ -5126,6 +5126,8 @@ sub vmconfig_update_net { >> $newnet->{trunks}, >> $newnet->{rate}, >> ); >> + # unplugging the interface dropped its forwarding database entries >> + PVE::QemuServer::Network::add_nets_bridge_fdb({ $opt => $value }, $vmid); >> >> } elsif (safe_num_ne($oldnet->{rate}, $newnet->{rate})) { >> # Rate can be applied on its own but any change above needs to >> @@ -5155,6 +5157,7 @@ sub vmconfig_update_net { >> $newnet->{bridge}, $newnet->{macaddr}, $vmid, $conf->{name}, >> ); >> vm_deviceplug($storecfg, $conf, $vmid, $opt, $newnet, $arch, $machine_type); >> + PVE::QemuServer::Network::add_nets_bridge_fdb({ $opt => $value }, $vmid); >> } else { >> die "skip\n"; >> } > > Not a qemu-server expert, but one thing I noticed: > > I think we need an eval around the two calls, otherwise when the `bridge fdb > add` fails, the tap interface is created but the hotplug fails (which means we > have a diverging config). Yes, I think it's preferable to only warn about failure here, while still proceeding, so that the VM config is updated. > I think we also should relax a bit the del_nets_bridge_fdb() function so that a > missing entry doesn't die (again add an eval around the `bridge fdb del`). Sounds good to me too :) > @Fiona what do you think? :)