From nobody Wed May 14 03:57:26 2025 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 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1530488869933303.45117114244215; Sun, 1 Jul 2018 16:47:49 -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 4C221C04AC48; Sun, 1 Jul 2018 23:47:48 +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 1792D5E7A2; Sun, 1 Jul 2018 23:47:48 +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 C3C024A464; Sun, 1 Jul 2018 23:47:47 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w61Nl6dd024812 for ; Sun, 1 Jul 2018 19:47:06 -0400 Received: by smtp.corp.redhat.com (Postfix) id 5A9DF2156889; Sun, 1 Jul 2018 23:47:06 +0000 (UTC) Received: from vhost2.laine.org (ovpn-116-116.phx2.redhat.com [10.3.116.116]) by smtp.corp.redhat.com (Postfix) with ESMTP id E072D2156880 for ; Sun, 1 Jul 2018 23:47:05 +0000 (UTC) From: Laine Stump To: libvir-list@redhat.com Date: Sun, 1 Jul 2018 19:46:58 -0400 Message-Id: <20180701234658.667147-4-laine@laine.org> In-Reply-To: <20180701234658.667147-1-laine@laine.org> References: <20180701234658.667147-1-laine@laine.org> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 3/3] network: properly check for taps that are connected to an OVS bridge 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: , MIME-Version: 1.0 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.31]); Sun, 01 Jul 2018 23:47:48 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" When libvirtd is restarted, it checks that each guest tap device is still attached to the bridge device that the configuration info says it should be connected to. If not, the tap will be disconnected from [wherever it is] and connected to [wherever it should be]. The previous code that did this did not account for: 1) the IFLA_MASTER attribute in a netdev's ifinfo will be set to "ovs-system" for any tap device connected to an OVS bridge, *not* to the name of the bridge it is attached to. 2) virNetDevRemovePort() only works for devices that are attached to a standard Linux host bridge. If a device is currently attached to an OVS bridge, then virNetDevOpenvswitchRemovePort() must be called instead. The result was an error message like this: error : virNetDevBridgeRemovePort:743 : Unable to remove bridge ovs-system port vnet1: Operation not supported This patch remedies those problems, and adds a couple of information log messages to aid in debugging any future problem. Resolves: https://bugzilla.redhat.com/1596176 Signed-off-by: Laine Stump --- src/network/bridge_driver.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index ac849581ec..da3c32e305 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -64,6 +64,7 @@ #include "virnetdev.h" #include "virnetdevip.h" #include "virnetdevbridge.h" +#include "virnetdevopenvswitch.h" #include "virnetdevtap.h" #include "virnetdevvportprofile.h" #include "virpci.h" @@ -4823,19 +4824,35 @@ networkNotifyActualDevice(virDomainDefPtr dom, =20 /* see if we're connected to the correct bridge */ if (netdef->bridge) { + bool useOVS =3D false; + if (virNetDevGetMaster(iface->ifname, &master) < 0) goto error; =20 + /* IFLA_MASTER for a tap on an OVS switch is always "ovs-system" */ + if (STREQ_NULLABLE(master, "ovs-system")) { + useOVS =3D true; + VIR_FREE(master); + if (virNetDevOpenvswitchInterfaceGetMaster(iface->ifname, &mas= ter) < 0) + goto error; + } + if (STRNEQ_NULLABLE(netdef->bridge, master)) { /* disconnect from current (incorrect) bridge */ - if (master) - ignore_value(virNetDevBridgeRemovePort(master, iface->ifna= me)); + if (master) { + VIR_INFO("Removing %s from %s", iface->ifname, master); + if (useOVS) + ignore_value(virNetDevOpenvswitchRemovePort(master, if= ace->ifname)); + else + ignore_value(virNetDevBridgeRemovePort(master, iface->= ifname)); + } =20 /* attach/reattach to correct bridge. * NB: we can't notify the guest of any MTU change anyway, * so there is no point in trying to learn the actualMTU * (final arg to virNetDevTapAttachBridge()) */ + VIR_INFO("Attaching %s to %s", iface->ifname, netdef->bridge); if (virNetDevTapAttachBridge(iface->ifname, netdef->bridge, &iface->mac, dom->uuid, virDomainNetGetActualVirtPortProf= ile(iface), --=20 2.14.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list