From nobody Tue May 21 16:27:08 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1568988408; cv=none; d=zoho.com; s=zohoarc; b=JpkmEiwhw93Gee3Nrd4YIQISN82gREPL7LPPNwhirBd0Z1Mh6rBZfLpQx3cUYk0kZW/Exk58tIzQt2fhqS+rF78bgogdIgMgGhj6kJzNPNZtCsoF31c3VI2AfopIe7QRuAUmaWfR1eQAQz97fv/cclXZF1AqvzX75yj6UKnrKS4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568988408; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=WlWlo00FKcVtdzalB/rayz9W86k3v6oMFkA/CfAGcWQ=; b=ZbvAuExTaHs+7zrjX81UcagB5QLsHsq0Bn2hoXwmbCFME+0VFC+LDTZf8tqOHUx5Uqlxe77OlMkCsj/3G2rq5perItEYV7lZxPqowqFqFySdHMUOVN/1VRnyFwrVvejGx89NcF1xMH/MPZg2rP41zaTOfRPHqm4yL/FgIr6JAyA= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1568988408556433.4763248139882; Fri, 20 Sep 2019 07:06:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5F729368DA; Fri, 20 Sep 2019 14:06:46 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D5A7C5C1B5; Fri, 20 Sep 2019 14:06:45 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id C6B2C1803B37; Fri, 20 Sep 2019 14:06:44 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x8KE6huQ014847 for ; Fri, 20 Sep 2019 10:06:43 -0400 Received: by smtp.corp.redhat.com (Postfix) id A69565DC1B; Fri, 20 Sep 2019 14:06:43 +0000 (UTC) Received: from vhost2.laine.org (ovpn-116-46.phx2.redhat.com [10.3.116.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E57B6D09E; Fri, 20 Sep 2019 14:06:40 +0000 (UTC) From: Laine Stump To: libvir-list@redhat.com Date: Fri, 20 Sep 2019 10:06:35 -0400 Message-Id: <20190920140635.11730-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] conf: reattach interface taps to correct bridge on restart X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 20 Sep 2019 14:06:47 +0000 (UTC) Content-Type: text/plain; charset="utf-8" When the bridge re-attach handling was moved out of the network driver and into the hypervisor driver (commit b806a60e) as a part of the refactor to split the network driver into a separate daemon, the check was accidentally changed to only check for type=3D'bridge'. The check for type in this case needs to check for type=3D'network' as well. (at the time we thought that type=3D'network' and type=3D'bridge' could be conflated for interface actual type, but this turned out to be too problematic to do). Signed-off-by: Laine Stump Reviewed-by: Daniel P. Berrang=C3=A9 --- (NB: I thought I remembered seeing a bugzilla report go by about this regression, but couldn't find it in any of the places I frequent (upstream, Fedora, or RHEL) If someone can locate it and wants to let me know the BZ#, I can add it to the commit message and update the report). (This fixes the reconnect of taps to their bridges, but the count maintained in the network object still isn't being updated in these cases. I've tried removing the !virUUIDIsValid() check in this same chunk, along with preserving the original port uuid if it's already valid in virDomainNetDefActualToNetworkPort(), and that results in fixing the usage count for type=3D'network' when it's a libvirt-managed bridge or a macvtap passthrough pool, but leads to errors in other cases.) src/conf/domain_conf.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 848c831330..24223bceb2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -30971,13 +30971,16 @@ virDomainNetNotifyActualDevice(virConnectPtr conn, virDomainDefPtr dom, virDomainNetDefPtr iface) { + virDomainNetType actualType =3D virDomainNetGetActualType(iface); + if (!virUUIDIsValid(iface->data.network.portid)) { if (virDomainNetCreatePort(conn, dom, iface, VIR_NETWORK_PORT_CREATE_RECLAIM) < 0) return; } =20 - if (virDomainNetGetActualType(iface) =3D=3D VIR_DOMAIN_NET_TYPE_BRIDGE= ) { + if (actualType =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK || + actualType =3D=3D VIR_DOMAIN_NET_TYPE_BRIDGE) { /* * NB: we can't notify the guest of any MTU change anyway, * so there is no point in trying to learn the actualMTU --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list