From nobody Mon May 6 06:00:56 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 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=1591212084; cv=none; d=zohomail.com; s=zohoarc; b=RBrgLpus9Kzgt0CZY66TS7IPt6I538EfkDRdL4b2UN4SJrvd1k6z3Ev7L55DojTyKKz9NbtrOcgDtubdRlwbsO63NBO7aizKGixfGy3eWxwciXS7k6PEBP6yakg9HUf8dX9QFvSUvZOuHqvWHEK4DRevN3h1PNmNWohq5Ebqs6Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1591212084; 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; bh=IS+1Og0I9XAD2WwKDYMJOq0rEEaUCSFftgzXJv7x3T0=; b=c1V/e8FnxdCI2zRs7AVtmg5be8WEeRfLSapPdeLMBKwu2Jh82yrts7UxphRCa3OZYnDDXZWBneFmPZX5ydOh0J0HK6e+VS7A6X586ajbJwmDrwFmhJ92gZnJqU9fVjt+KIsQGqVRxsHVPUoZ/r/qDxC142x5o9pwNAAY2SengUE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1591212084075876.1569250766286; Wed, 3 Jun 2020 12:21:24 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-347-xO1LmaTaM9-glrmtG7p6gQ-1; Wed, 03 Jun 2020 15:21:20 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BA54E835B42; Wed, 3 Jun 2020 19:21:14 +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 058376AD00; Wed, 3 Jun 2020 19:21:13 +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 69F9E1809543; Wed, 3 Jun 2020 19:21:07 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 053JL5AU019113 for ; Wed, 3 Jun 2020 15:21:05 -0400 Received: by smtp.corp.redhat.com (Postfix) id CDA7137DD; Wed, 3 Jun 2020 19:21:05 +0000 (UTC) Received: from vhost2.laine.org (ovpn-113-82.phx2.redhat.com [10.3.113.82]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8A34560BE1 for ; Wed, 3 Jun 2020 19:20:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591212082; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=IS+1Og0I9XAD2WwKDYMJOq0rEEaUCSFftgzXJv7x3T0=; b=V5T5dNpSCX1qH8ct+fVib+59dFhh3/XGgrfVqGL+lBmirP1wNq0HaXEG72ys6WQ9pwOxyy Q2waT80heTKAjD6CgOa2+Dfc+mbA7UfywTRLKdDhp8l4LCgqq3LKD9oZZgNxaf07F/sTue oqiV43svw2a9cmOg3mD1TfRHPefsaAg= X-MC-Unique: xO1LmaTaM9-glrmtG7p6gQ-1 From: Laine Stump To: libvir-list@redhat.com Subject: [libvirt PATCH] qemu: don't reject interface update when switching to/from bridged network Date: Wed, 3 Jun 2020 15:20:55 -0400 Message-Id: <20200603192055.39105-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" If virDomainUpdateDeviceFlags() was used to update an , and the interface type changed from type=3D'network' where the network was an unmanaged bridge (so actualType =3D=3D bridge) to type=3D'bridge' (i.e. actualType *also* =3D=3D bridge), the update would fail due to the perceived change in type. In practice it is okay to switch between any interface types that end up using a tap device, since libvirt just needs to attach the device to a new bridge. But in this case we were erroneously rejecting it due to a conditional that was too restrictive. This is what the code was doing: if (old->type !=3D new->type) [allow update] else if ((oldActual =3D=3D bridge and newActual =3D=3D network) || (oldActual =3D=3D network and newActual =3D=3D bridge)) { [allow update] else [error] In the case described above though, old->type and new->type don't match, but oldActual and newActual are both 'bridge', so we get an error. This patch changes the inner conditional so that any combination of 'network' and 'bridge' for oldActual and newActual, since they both use a tap device connected to a bridge. Signed-off-by: Laine Stump Reviewed-by: Daniel Henrique Barboza Reviewed-by: Michal Privoznik --- src/qemu/qemu_hotplug.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index a5d57702eb..dc3bd8245f 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3770,15 +3770,15 @@ qemuDomainChangeNet(virQEMUDriverPtr driver, * where this can only require a minor (or even no) change, * but in most cases we need to do a full reconnection. * - * If we switch (in either direction) between type=3D'bridge' - * and type=3D'network' (for a traditional managed virtual - * network that uses a host bridge, i.e. forward - * mode=3D'route|nat'), we just need to change the bridge. + * As long as both the new and old types use a tap device + * connected to a host bridge (ie VIR_DOMAIN_NET_TYPE_NETWORK + * or VIR_DOMAIN_NET_TYPE_BRIDGE), we just need to connect to + * the new bridge. */ - if ((oldType =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK && - newType =3D=3D VIR_DOMAIN_NET_TYPE_BRIDGE) || - (oldType =3D=3D VIR_DOMAIN_NET_TYPE_BRIDGE && - newType =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK)) { + if ((oldType =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK || + oldType =3D=3D VIR_DOMAIN_NET_TYPE_BRIDGE) && + (newType =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK || + newType =3D=3D VIR_DOMAIN_NET_TYPE_BRIDGE)) { =20 needBridgeChange =3D true; =20 --=20 2.25.4