From nobody Sun Feb 8 17:21:37 2026 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 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1552999639823879.9680407931025; Tue, 19 Mar 2019 05:47:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 092602D7E0; Tue, 19 Mar 2019 12:47:18 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D57E62967F; Tue, 19 Mar 2019 12:47:17 +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 80BE23FB30; Tue, 19 Mar 2019 12:47:17 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x2JClFpX028763 for ; Tue, 19 Mar 2019 08:47:15 -0400 Received: by smtp.corp.redhat.com (Postfix) id C28BC5D707; Tue, 19 Mar 2019 12:47:15 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 99D765D75C; Tue, 19 Mar 2019 12:47:12 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Tue, 19 Mar 2019 12:46:29 +0000 Message-Id: <20190319124700.16722-6-berrange@redhat.com> In-Reply-To: <20190319124700.16722-1-berrange@redhat.com> References: <20190319124700.16722-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v3 05/36] network: use 'bridge' as actual type instead of 'network' 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-Type: text/plain; charset="utf-8" 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.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 19 Mar 2019 12:47:18 +0000 (UTC) Ports allocated on virtual networks with type=3Dnat|route|open all get given an actual type of 'network'. Only ports in networks with type=3Dbridge use an actual type of 'bridge'. This distinction makes little sense since the virtualization drivers will treat both actual types in exactly the same way, as they're all just bridge devices a VM needs to be connected to. This doesn't affect user visible XML since the "actual" device XML is internal only, but we need code to convert the data upgrades. Signed-off-by: Daniel P. Berrang=C3=A9 --- src/network/bridge_driver.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 4770dd1e4e..40122612c8 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -4454,11 +4454,7 @@ networkAllocateActualDevice(virNetworkPtr net, case VIR_NETWORK_FORWARD_NAT: case VIR_NETWORK_FORWARD_ROUTE: case VIR_NETWORK_FORWARD_OPEN: - /* for these forward types, the actual net type really *is* - * NETWORK; we just keep the info from the portgroup in - * iface->data.network.actual - */ - iface->data.network.actual->type =3D VIR_DOMAIN_NET_TYPE_NETWORK; + iface->data.network.actual->type =3D VIR_DOMAIN_NET_TYPE_BRIDGE; =20 /* we also store the bridge device and macTableManager settings * in iface->data.network.actual->data.bridge for later use @@ -4832,6 +4828,15 @@ networkNotifyActualDevice(virNetworkPtr net, netdef->bridge) < 0)) goto error; =20 + /* Older libvirtd uses actualType=3D=3Dnetwork, but we now + * just use actualType=3D=3Dbridge, as nothing needs to + * distinguish the two cases, and this simplifies virt + * drive code */ + if (actualType =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK) { + iface->data.network.actual->type =3D VIR_DOMAIN_NET_TYPE_BRIDGE; + actualType =3D VIR_DOMAIN_NET_TYPE_BRIDGE; + } + /* see if we're connected to the correct bridge */ if (netdef->bridge) { bool useOVS =3D false; @@ -5475,9 +5480,8 @@ networkBandwidthGenericChecks(virDomainNetDefPtr ifac= e, virNetDevBandwidthPtr ifaceBand; unsigned long long old_floor, new_floor; =20 - if (virDomainNetGetActualType(iface) !=3D VIR_DOMAIN_NET_TYPE_NETWORK = && - (virDomainNetGetActualType(iface) !=3D VIR_DOMAIN_NET_TYPE_BRIDGE = || - iface->data.network.actual->data.bridge.brname =3D=3D NULL)) { + if (virDomainNetGetActualType(iface) !=3D VIR_DOMAIN_NET_TYPE_BRIDGE || + iface->data.network.actual->data.bridge.brname =3D=3D NULL) { /* This is not an interface that's plugged into a network. * We don't care. Thus from our POV bandwidth change is allowed. */ return false; --=20 2.20.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list