[PATCH] lxc: don't try to reserve macvtap name for LXC domains

Laine Stump laine at redhat.com
Mon Dec 14 21:30:48 UTC 2020


Commit 729a06c41 added code to the LXC driver (patterned after similar
code in the QEMU driver) that called
virNetDevMacVlanReserveName(net->ifname) for all type='direct'
interfaces during a libvirtd restart, to prevent other domains from
attempting to use a macvtap device name that was already in use by a
domain.

But, unlike a QEMU domain, when an LXC domain creates a macvtap
device, that device is almost immediately moved into the namespace of
the container (and it's then renamed, but that part isn't
important). Because of this, the LXC driver doesn't keep track (in
net->ifname) of the name used to create the device (as the QEMU driver
does).

The result of this is that if libvirtd is restarted while there is an
active LXC domain that has <interface type='direct'>, libvirtd will
segfault (since virNetDevMacVLanReserveName() doesn't check for a NULL
pointer).

The fix is to just not call that function in the case of the LXC
driver, since it is pointless anyway.

Signed-off-by: Laine Stump <laine at redhat.com>
---
 src/lxc/lxc_process.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c
index 0f818e2ee0..79d84617d1 100644
--- a/src/lxc/lxc_process.c
+++ b/src/lxc/lxc_process.c
@@ -1635,13 +1635,6 @@ virLXCProcessReconnectNotifyNets(virDomainDefPtr def)
 
     for (i = 0; i < def->nnets; i++) {
         virDomainNetDefPtr net = def->nets[i];
-        /* keep others from trying to use the macvtap device name, but
-         * don't return error if this happens, since that causes the
-         * domain to be unceremoniously killed, which would be *very*
-         * impolite.
-         */
-        if (virDomainNetGetActualType(net) == VIR_DOMAIN_NET_TYPE_DIRECT)
-            virNetDevMacVLanReserveName(net->ifname);
 
         if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
             if (!conn && !(conn = virGetConnectNetwork()))
-- 
2.28.0




More information about the libvir-list mailing list