From nobody Tue Feb 10 05:25:55 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.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; Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1493146249613215.17976336266497; Tue, 25 Apr 2017 11:50:49 -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 9ABCF80487; Tue, 25 Apr 2017 18:50:47 +0000 (UTC) Received: from colo-mx.corp.redhat.com (unknown [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 703FF79C79; Tue, 25 Apr 2017 18:50:47 +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 22D445EC66; Tue, 25 Apr 2017 18:50:47 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v3PIoh4o030931 for ; Tue, 25 Apr 2017 14:50:43 -0400 Received: by smtp.corp.redhat.com (Postfix) id 85DE67F599; Tue, 25 Apr 2017 18:50:43 +0000 (UTC) Received: from vhost2.laine.org (ovpn-116-65.phx2.redhat.com [10.3.116.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id 290A317CC1; Tue, 25 Apr 2017 18:50:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9ABCF80487 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=laine.org Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=libvir-list-bounces@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9ABCF80487 From: Laine Stump To: libvir-list@redhat.com Date: Tue, 25 Apr 2017 14:50:36 -0400 Message-Id: <20170425185037.14805-3-laine@laine.org> In-Reply-To: <20170425185037.14805-1-laine@laine.org> References: <20170425185037.14805-1-laine@laine.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Cc: Martin Kletzander Subject: [libvirt] [PATCH v2 2/3] conf: don't ignore for macvtap interfaces 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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 25 Apr 2017 18:50:48 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The parser had been clearing out *all* suggested device names for type=3D'direct' (aka macvtap) interfaces. All of the code implementing macvtap allows for a user-specified device name, so we should allow it. In the case that an interface name starts with "macvtap" or "macvlan" though, we do still clear it out, just as we do with "vnet" (which is the prefix used for automatically generated tap device names), since those are the prefixes for the names we autogenerate for macvtap and macvlan devices. Resolves: https://bugzilla.redhat.com/1335798 squash --- docs/formatdomain.html.in | 6 +++--- src/conf/domain_conf.c | 7 ++++++- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index e31a271..58cd3cf 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5175,9 +5175,9 @@ qemu-kvm -net nic,model=3D? /dev/null If no target is specified, certain hypervisors will automatically generate a name for the created tun device. This name can be manually specified, however the name should not - start with either 'vnet' or 'vif', which are prefixes - reserved by libvirt and certain hypervisors. Manually specified - targets using these prefixes may be ignored. + start with either 'vnet', 'vif', 'macvtap', or 'macvlan', + which are prefixes reserved by libvirt and certain hypervisors. + Manually specified targets using these prefixes may be ignored.

=20

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index fe9b7c7..36644b8 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -55,6 +55,7 @@ #include "virtpm.h" #include "virstring.h" #include "virnetdev.h" +#include "virnetdevmacvlan.h" #include "virhostdev.h" #include "virmdev.h" =20 @@ -10028,8 +10029,12 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlo= pt, def->data.direct.linkdev =3D dev; dev =3D NULL; =20 - if (flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) + if (ifname && + flags & VIR_DOMAIN_DEF_PARSE_INACTIVE && + (STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX) || + STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX))) { VIR_FREE(ifname); + } =20 break; =20 --=20 2.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list