From nobody Fri May 3 11:04:38 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=1598158356; cv=none; d=zohomail.com; s=zohoarc; b=MM6pgLM3XueCHMVpQmEK2ovsyE8BClreRfyFM+4nFQk95sQukwZqUTD3KcVuJmK+hgEtBI6ppzxTaa20P7gsNlq/vZADMFm/HuCBFa6poTrm4BxSdD0NLq3WSe+KVn8Pk0rN/JHtDCo2MrWR9GgozkfVNm7Q5NREBp0ruZXI8zo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1598158356; 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=gEtUwj4kot77Bgghl1ub/UF3Zsiipfs8ZBiYia0afdQ=; b=KE1MmjDHFJZvWjqf9iSsvIsedPsWSjBbGImjEBXKpA9cgJy1KRErFNIhQ326QokoO4pztu+x1re2aZnO2k5YAsEQbt8PoEiMr8eSFsaqXjppgPn44Kzp0ZgUAWFDPoYQ3UUUFQvl9nkfpwAEZ97Q0S0NdrK7KcTEg3T0cqwo5TY= 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 1598158356798200.04274598303766; Sat, 22 Aug 2020 21:52:36 -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-211-gMQhuH7ANuGV6-yvG1bTMQ-1; Sun, 23 Aug 2020 00:52:33 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58704801AC8; Sun, 23 Aug 2020 04:52:27 +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 DD13F7AEEE; Sun, 23 Aug 2020 04:52:26 +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 98A7C180B655; Sun, 23 Aug 2020 04:52:25 +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 07N4qOu9032217 for ; Sun, 23 Aug 2020 00:52:24 -0400 Received: by smtp.corp.redhat.com (Postfix) id 0892C7AEEE; Sun, 23 Aug 2020 04:52:24 +0000 (UTC) Received: from vhost2.laine.org (ovpn-113-64.phx2.redhat.com [10.3.113.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id B55D17AEDD for ; Sun, 23 Aug 2020 04:52:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598158355; 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=gEtUwj4kot77Bgghl1ub/UF3Zsiipfs8ZBiYia0afdQ=; b=CYgGimA8ezubNH5xDkPflhmJgA9NX7pXTm0RQKQ/z1F8EtUQmVZvZKyq+/ubvNm2JPit0d 5w37Io/+rTcASIceKZt1oR2dQi3X7Wu4w0XUxZAXjZqu0r5cepeD3DQm0OIzVwX+9w6zsH gBzn0VAhQzSrEdVwg4SzKxddKOE7AIc= X-MC-Unique: gMQhuH7ANuGV6-yvG1bTMQ-1 From: Laine Stump To: libvir-list@redhat.com Subject: [libvirt PATCH] conf: properly clear out autogenerated macvtap names when formatting/parsing Date: Sun, 23 Aug 2020 00:52:18 -0400 Message-Id: <20200823045218.588366-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Back when macvtap support was added in commit 315baab9443 in Feb. 2010 (libvirt-0.7.7), it was setup to autogenerate a name for the device if one wasn't supplied, in the pattern "macvtap%d" (or "macvlan%d"), similar to the way an unspecified standard tap device name will lead to an autogenerated "vnet%d". As a matter of fact, in commit ca1b7cc8e45 added in May 2010, the code was changed to *always* ignore a supplied device name for macvtap interfaces by deleting any name immediately during the parsing (this was intended to prevent one domain which had failed to completely start from deleting the macvtap device of another domain which had subsequently been provided the same device name (this will seem mildly ironic later). This was later fixed to only clear the device name when inactive XML was being parsed. HOWEVER - this was only done if the xml was - autogenerated names were not cleared for (which could also result in a macvtap device). Although the names of "vnetX" tap devices had always been automatically cleared when parsing (see commit d1304583d from July 2008 (!)), at the time macvtap support was added, both vnetX and macvtapX device names were always included when formatting the XML. Then in commit a8be259d0cc (July 2011, libvirt-0.9.4), formatting was changed to also clear out "vnetX" device names during XML formatting as well. However the same treatment wasn't given to "macvtapX". The result of all this (among other things) was that when a running guest Now in 2020, there has been a report that a failed migration leads to the macvtap device of some other unrelated guest on the destination host losing its network connectivity. It was determined that this was due to the domain XML in the migration containing a macvtap device name, e.g. "macvtap0", that was already in use on the destination. Normally this wouldn't be a problem, because libvirt would see that the device was already in use, and then find a different unused name. But in this case, other external problems were causing the migration to fail prior to selecting a macvtap device and successfully opening it, and during error recovery, qemuProcessStop() was called, which went through all def->nets objects and (if they were macvtap) deleted the device specified in net->ifname; since libvirt hadn't gotten to the point of replacing the incoming "macvtap0" with the name of a device it actually created for this guest, that meant that "macvtap0" was deleted, *even though it was currently in use by a different guest*! Whew! So, it turns out that when formatting "migratable" XML, "vnetX" devices are omitted, just as when formatting "inactive" XML (I'm sure there's a bit of code somewhere that says "if (migratable) then set inactive too", but found it was easier to just try it out with "virsh dumpxml blah --migratable"). By making the code in both interface parsing and formatting consistent for "vnetX", "macvtapX", and "macvlanX", we can thus make sure that the autogenerated (and unneeded / completely *not* wanted) macvtap device name will not be sent with the migration XML. This way when a migration fails, net->ifname will be NULL, and libvirt won't have any device to try and delete. Signed-off-by: Laine Stump Reviewed-by: Daniel Henrique Barboza --- src/conf/domain_conf.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 8e7981bf25..6064d31b99 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -12428,14 +12428,6 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlo= pt, } =20 def->data.direct.linkdev =3D g_steal_pointer(&dev); - - if (ifname && - flags & VIR_DOMAIN_DEF_PARSE_INACTIVE && - (STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX) || - STRPREFIX(ifname, VIR_NET_GENERATED_MACVLAN_PREFIX))) { - VIR_FREE(ifname); - } - break; =20 case VIR_DOMAIN_NET_TYPE_HOSTDEV: @@ -12481,6 +12473,8 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlop= t, if (def->managed_tap !=3D VIR_TRISTATE_BOOL_NO && ifname && (flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) && (STRPREFIX(ifname, VIR_NET_GENERATED_TAP_PREFIX) || + STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX) || + STRPREFIX(ifname, VIR_NET_GENERATED_MACVLAN_PREFIX) || (prefix && STRPREFIX(ifname, prefix)))) { /* An auto-generated target name, blank it out */ VIR_FREE(ifname); @@ -26796,6 +26790,8 @@ virDomainNetDefFormat(virBufferPtr buf, (def->managed_tap =3D=3D VIR_TRISTATE_BOOL_NO || !((flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE) && (STRPREFIX(def->ifname, VIR_NET_GENERATED_TAP_PREFIX) || + STRPREFIX(def->ifname, VIR_NET_GENERATED_MACVTAP_PREFIX) || + STRPREFIX(def->ifname, VIR_NET_GENERATED_MACVLAN_PREFIX) || (prefix && STRPREFIX(def->ifname, prefix)))))) { /* Skip auto-generated target names for inactive config. */ virBufferEscapeString(&attrBuf, " dev=3D'%s'", def->ifname); --=20 2.26.2