2011-11-02 17:11:02 +00:00
|
|
|
/*
|
2017-03-05 22:32:15 +00:00
|
|
|
* Copyright (C) 2010-2017 Red Hat, Inc.
|
2012-02-22 13:17:14 +00:00
|
|
|
* Copyright (C) 2010-2012 IBM Corporation
|
2011-11-02 17:11:02 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-09-20 22:30:55 +00:00
|
|
|
* License along with this library. If not, see
|
2012-07-21 10:06:23 +00:00
|
|
|
* <http://www.gnu.org/licenses/>.
|
2011-11-02 17:11:02 +00:00
|
|
|
*
|
2022-05-24 07:23:18 +00:00
|
|
|
* Notes: iproute2 package
|
2011-11-02 17:11:02 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
#include "virnetdevmacvlan.h"
|
2012-01-27 17:23:05 +00:00
|
|
|
#include "virmacaddr.h"
|
2012-12-13 18:21:53 +00:00
|
|
|
#include "virerror.h"
|
2011-11-02 17:11:02 +00:00
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_NET
|
|
|
|
|
2019-03-16 18:20:32 +00:00
|
|
|
VIR_ENUM_IMPL(virNetDevMacVLanMode,
|
|
|
|
VIR_NETDEV_MACVLAN_MODE_LAST,
|
2011-11-02 17:11:02 +00:00
|
|
|
"vepa",
|
|
|
|
"private",
|
|
|
|
"bridge",
|
2019-01-20 16:30:15 +00:00
|
|
|
"passthrough",
|
|
|
|
);
|
2011-11-02 17:11:02 +00:00
|
|
|
|
build: eliminate WITH_MACVTAP flag entirely
This flag was originally created to indicate that either 1) the build
platform wasn't linux, 2) the build platform was linux, but the kernel
was too old to have macvtap support. Since there was already a switch
there, the ability to also disable it when 3) the kernel supports
macvtap but the user doesn't want it, was added in. I don't think that
(3) was ever an intentional goal, just something that grew naturally
out of having the flag there in the first place (unless possibly the
original author wanted a way to quickly disable their new code in case
it caused regressions elsewhere).
Now that the check for (2) has been removed, WITH_MACVTAP is just
checking (1) and (3), but (3) is pointless (because the extra code in
libvirt itself is miniscule, and the only external library needed for
it is libnl, which is also required for other unrelated features (and
itself has no subordinate dependencies and takes up < 1MB on
disk)). We can therfore eliminate the WITH_MACVTAP flag, as it is
functionally equivalent to WITH_LIBNL (which implies __linux__).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-29 14:54:38 +00:00
|
|
|
#if defined(WITH_LIBNL)
|
2011-11-02 17:11:02 +00:00
|
|
|
# include <fcntl.h>
|
|
|
|
|
2013-06-13 06:26:22 +00:00
|
|
|
# include <net/if.h>
|
2011-11-02 17:11:02 +00:00
|
|
|
# include <linux/if_tun.h>
|
|
|
|
|
2012-12-12 18:06:53 +00:00
|
|
|
# include "viralloc.h"
|
2012-12-12 17:59:27 +00:00
|
|
|
# include "virlog.h"
|
2012-12-13 18:01:25 +00:00
|
|
|
# include "viruuid.h"
|
2011-11-02 17:11:02 +00:00
|
|
|
# include "virfile.h"
|
2012-02-03 14:13:19 +00:00
|
|
|
# include "virnetlink.h"
|
2011-11-02 17:11:02 +00:00
|
|
|
# include "virnetdev.h"
|
2012-02-22 13:17:14 +00:00
|
|
|
# include "virpidfile.h"
|
2016-01-19 19:20:54 +00:00
|
|
|
# include "virbitmap.h"
|
2020-01-14 17:38:59 +00:00
|
|
|
# include "virsocket.h"
|
2012-02-22 13:17:14 +00:00
|
|
|
|
2014-02-28 12:16:17 +00:00
|
|
|
VIR_LOG_INIT("util.netdevmacvlan");
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2013-02-28 14:59:01 +00:00
|
|
|
|
2019-08-26 05:24:08 +00:00
|
|
|
/**
|
|
|
|
* virNetDevMacVLanIsMacvtap:
|
|
|
|
* @ifname: Name of the interface
|
|
|
|
*
|
|
|
|
* Return T if the named netdev exists and is a macvtap device
|
|
|
|
* F in all other cases.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
virNetDevMacVLanIsMacvtap(const char *ifname)
|
|
|
|
{
|
|
|
|
int ifindex;
|
2019-10-15 13:16:31 +00:00
|
|
|
g_autofree char *tapname = NULL;
|
2019-08-26 05:24:08 +00:00
|
|
|
|
|
|
|
if (virNetDevGetIndex(ifname, &ifindex) < 0)
|
|
|
|
return false;
|
|
|
|
|
2019-10-22 13:26:14 +00:00
|
|
|
tapname = g_strdup_printf("/dev/tap%d", ifindex);
|
2019-08-26 05:24:08 +00:00
|
|
|
|
|
|
|
return virFileExists(tapname);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-11-02 17:34:41 +00:00
|
|
|
/**
|
|
|
|
* virNetDevMacVLanCreate:
|
|
|
|
*
|
|
|
|
* @ifname: The name the interface is supposed to have; optional parameter
|
|
|
|
* @macaddress: The MAC address of the device
|
|
|
|
* @srcdev: The name of the 'link' device
|
|
|
|
* @macvlan_mode: The macvlan mode to use
|
2020-12-14 01:50:34 +00:00
|
|
|
* @flags: OR of virNetDevMacVLanCreateFlags.
|
2011-11-02 17:34:41 +00:00
|
|
|
*
|
|
|
|
* Create a macvtap device with the given properties.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 on fatal error.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
virNetDevMacVLanCreate(const char *ifname,
|
2013-10-05 19:41:44 +00:00
|
|
|
const virMacAddr *macaddress,
|
2011-11-02 17:34:41 +00:00
|
|
|
const char *srcdev,
|
2020-12-14 01:50:34 +00:00
|
|
|
uint32_t macvlan_mode,
|
|
|
|
unsigned int flags)
|
2011-11-02 17:34:41 +00:00
|
|
|
{
|
2018-09-07 07:17:26 +00:00
|
|
|
int error = 0;
|
|
|
|
int ifindex = 0;
|
2020-12-14 01:50:34 +00:00
|
|
|
const char *type = (flags & VIR_NETDEV_MACVLAN_CREATE_WITH_TAP ?
|
|
|
|
"macvtap" : "macvlan");
|
2018-09-07 07:17:26 +00:00
|
|
|
virNetlinkNewLinkData data = {
|
|
|
|
.macvlan_mode = &macvlan_mode,
|
|
|
|
.mac = macaddress,
|
|
|
|
};
|
2011-11-02 17:34:41 +00:00
|
|
|
|
2018-09-07 07:17:26 +00:00
|
|
|
if (virNetDevGetIndex(srcdev, &ifindex) < 0)
|
2011-11-02 17:34:41 +00:00
|
|
|
return -1;
|
|
|
|
|
2018-09-07 07:17:26 +00:00
|
|
|
data.ifindex = &ifindex;
|
|
|
|
if (virNetlinkNewLink(ifname, type, &data, &error) < 0) {
|
|
|
|
char macstr[VIR_MAC_STRING_BUFLEN];
|
2011-11-02 17:34:41 +00:00
|
|
|
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
virReportSystemError(-error,
|
|
|
|
_("error creating %s interface %s@%s (%s)"),
|
|
|
|
type, ifname, srcdev,
|
|
|
|
virMacAddrFormat(macaddress, macstr));
|
2018-09-07 07:17:26 +00:00
|
|
|
return -1;
|
2011-11-02 17:34:41 +00:00
|
|
|
}
|
|
|
|
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
VIR_INFO("created device: '%s'", ifname);
|
2018-09-07 07:17:26 +00:00
|
|
|
return 0;
|
2011-11-02 17:34:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNetDevMacVLanDelete:
|
|
|
|
*
|
|
|
|
* @ifname: Name of the interface
|
|
|
|
*
|
|
|
|
* Tear down an interface with the given name.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 on fatal error.
|
|
|
|
*/
|
|
|
|
int virNetDevMacVLanDelete(const char *ifname)
|
|
|
|
{
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
VIR_INFO("delete device: '%s'", ifname);
|
util: fallback to ioctl(SIOCBRDELBR) if netlink RTM_DELLINK fails
commit 09778e09 switched from using ioctl(SIOCBRDELBR) for bridge
device deletion to using a netlink RTM_DELLINK message, which is the
more modern way to delete a bridge (and also doesn't require the
bridge to be ~IFF_UP to succeed). However, although older kernels
(e.g. 2.6.32, in RHEL6/CentOS6) support deleting *some* link types
with RTM_NEWLINK, they don't support deleting bridges, and there is no
compile-time way to figure this out.
This patch moves the body of the SIOCBRDELBR version of
virNetDevBridgeDelete() into a static function, calls the new function
from the original, and also calls the new function from the
RTM_DELLINK version if the RTM_DELLINK message generates an EOPNOTSUPP
error. Since RTM_DELLINK is done from the subordinate function
virNetlinkDelLink, which is also called for other purposes (deleting a
macvtap interface), a function pointer called "fallback" has been
added to the arglist of virNetlinkDelLink() - if that arg != NULL, the
provided function will be called when (and only when) RTM_DELLINK
fails with EOPNOTSUPP.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1252780 (part 2)
2015-08-26 03:19:03 +00:00
|
|
|
return virNetlinkDelLink(ifname, NULL);
|
2011-11-02 17:34:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-11-02 17:11:02 +00:00
|
|
|
/**
|
|
|
|
* virNetDevMacVLanTapOpen:
|
|
|
|
* @ifname: Name of the macvtap interface
|
2015-12-04 08:39:02 +00:00
|
|
|
* @tapfd: array of file descriptor return value for the new macvtap device
|
|
|
|
* @tapfdSize: number of file descriptors in @tapfd
|
|
|
|
*
|
|
|
|
* Open the macvtap's tap device, possibly multiple times if @tapfdSize > 1.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 otherwise.
|
2011-11-02 17:11:02 +00:00
|
|
|
*/
|
2019-08-26 05:51:40 +00:00
|
|
|
int
|
2015-12-04 08:39:02 +00:00
|
|
|
virNetDevMacVLanTapOpen(const char *ifname,
|
|
|
|
int *tapfd,
|
2019-08-26 05:51:40 +00:00
|
|
|
size_t tapfdSize)
|
2011-11-02 17:11:02 +00:00
|
|
|
{
|
2019-08-26 05:51:40 +00:00
|
|
|
int retries = 10;
|
2015-04-15 09:45:47 +00:00
|
|
|
int ret = -1;
|
2011-11-02 17:11:02 +00:00
|
|
|
int ifindex;
|
2015-12-04 08:39:02 +00:00
|
|
|
size_t i = 0;
|
2019-10-15 13:16:31 +00:00
|
|
|
g_autofree char *tapname = NULL;
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2015-12-04 09:55:49 +00:00
|
|
|
if (virNetDevGetIndex(ifname, &ifindex) < 0)
|
2011-11-02 17:11:02 +00:00
|
|
|
return -1;
|
|
|
|
|
2019-10-22 13:26:14 +00:00
|
|
|
tapname = g_strdup_printf("/dev/tap%d", ifindex);
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2015-12-04 08:39:02 +00:00
|
|
|
for (i = 0; i < tapfdSize; i++) {
|
|
|
|
int fd = -1;
|
|
|
|
|
|
|
|
while (fd < 0) {
|
|
|
|
if ((fd = open(tapname, O_RDWR)) >= 0) {
|
|
|
|
tapfd[i] = fd;
|
|
|
|
} else if (retries-- > 0) {
|
|
|
|
/* may need to wait for udev to be done */
|
2019-10-02 17:01:11 +00:00
|
|
|
g_usleep(20000);
|
2015-12-04 08:39:02 +00:00
|
|
|
} else {
|
|
|
|
/* However, if haven't succeeded, quit. */
|
|
|
|
virReportSystemError(errno,
|
|
|
|
_("cannot open macvtap tap device %s"),
|
|
|
|
tapname);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-04 08:39:02 +00:00
|
|
|
ret = 0;
|
|
|
|
|
2015-04-15 09:45:47 +00:00
|
|
|
cleanup:
|
2015-12-04 08:39:02 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
while (i--)
|
|
|
|
VIR_FORCE_CLOSE(tapfd[i]);
|
|
|
|
}
|
2015-04-15 09:45:47 +00:00
|
|
|
return ret;
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNetDevMacVLanTapSetup:
|
2015-12-04 10:19:32 +00:00
|
|
|
* @tapfd: array of file descriptors of the macvtap tap
|
|
|
|
* @tapfdSize: number of file descriptors in @tapfd
|
|
|
|
* @vnet_hdr: whether to enable or disable IFF_VNET_HDR
|
2015-12-08 12:17:26 +00:00
|
|
|
*
|
2015-12-13 06:54:46 +00:00
|
|
|
* Turn on the IFF_VNET_HDR flag if requested and available, but make sure
|
|
|
|
* it's off otherwise. Similarly, turn on IFF_MULTI_QUEUE if @tapfdSize is
|
|
|
|
* greater than one, but if it can't be set, consider it a fatal error
|
|
|
|
* (rather than ignoring as with @vnet_hdr).
|
2011-11-02 17:11:02 +00:00
|
|
|
*
|
|
|
|
* A fatal error is defined as the VNET_HDR flag being set but it cannot
|
|
|
|
* be turned off for some reason. This is reported with -1. Other fatal
|
|
|
|
* error is not being able to read the interface flags. In that case the
|
|
|
|
* macvtap device should not be used.
|
2015-12-04 10:19:32 +00:00
|
|
|
*
|
2015-12-08 12:17:26 +00:00
|
|
|
* Returns 0 on success, -1 in case of fatal error.
|
2011-11-02 17:11:02 +00:00
|
|
|
*/
|
2019-08-26 05:51:40 +00:00
|
|
|
int
|
2015-12-13 06:54:46 +00:00
|
|
|
virNetDevMacVLanTapSetup(int *tapfd, size_t tapfdSize, bool vnet_hdr)
|
2011-11-02 17:11:02 +00:00
|
|
|
{
|
|
|
|
unsigned int features;
|
|
|
|
struct ifreq ifreq;
|
|
|
|
short new_flags = 0;
|
2015-12-04 10:19:32 +00:00
|
|
|
size_t i;
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2015-12-04 10:19:32 +00:00
|
|
|
for (i = 0; i < tapfdSize; i++) {
|
|
|
|
memset(&ifreq, 0, sizeof(ifreq));
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2015-12-04 10:19:32 +00:00
|
|
|
if (ioctl(tapfd[i], TUNGETIFF, &ifreq) < 0) {
|
2011-11-02 17:11:02 +00:00
|
|
|
virReportSystemError(errno, "%s",
|
2015-12-04 10:19:32 +00:00
|
|
|
_("cannot get interface flags on macvtap tap"));
|
2011-11-02 17:11:02 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2015-12-04 10:19:32 +00:00
|
|
|
|
|
|
|
new_flags = ifreq.ifr_flags;
|
|
|
|
|
2015-12-08 12:17:26 +00:00
|
|
|
if (vnet_hdr) {
|
2015-12-04 10:19:32 +00:00
|
|
|
if (ioctl(tapfd[i], TUNGETFEATURES, &features) < 0) {
|
|
|
|
virReportSystemError(errno, "%s",
|
|
|
|
_("cannot get feature flags on macvtap tap"));
|
|
|
|
return -1;
|
|
|
|
}
|
2015-12-08 12:17:26 +00:00
|
|
|
if (features & IFF_VNET_HDR)
|
|
|
|
new_flags |= IFF_VNET_HDR;
|
|
|
|
} else {
|
|
|
|
new_flags &= ~IFF_VNET_HDR;
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
|
2015-12-13 06:54:46 +00:00
|
|
|
if (tapfdSize > 1)
|
2015-12-08 12:17:26 +00:00
|
|
|
new_flags |= IFF_MULTI_QUEUE;
|
|
|
|
else
|
|
|
|
new_flags &= ~IFF_MULTI_QUEUE;
|
|
|
|
|
2015-12-04 10:19:32 +00:00
|
|
|
if (new_flags != ifreq.ifr_flags) {
|
|
|
|
ifreq.ifr_flags = new_flags;
|
|
|
|
if (ioctl(tapfd[i], TUNSETIFF, &ifreq) < 0) {
|
2015-12-08 12:17:26 +00:00
|
|
|
virReportSystemError(errno, "%s",
|
|
|
|
_("unable to set vnet or multiqueue flags on macvtap"));
|
|
|
|
return -1;
|
2015-12-04 10:19:32 +00:00
|
|
|
}
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static const uint32_t modeMap[VIR_NETDEV_MACVLAN_MODE_LAST] = {
|
|
|
|
[VIR_NETDEV_MACVLAN_MODE_VEPA] = MACVLAN_MODE_VEPA,
|
|
|
|
[VIR_NETDEV_MACVLAN_MODE_PRIVATE] = MACVLAN_MODE_PRIVATE,
|
|
|
|
[VIR_NETDEV_MACVLAN_MODE_BRIDGE] = MACVLAN_MODE_BRIDGE,
|
|
|
|
[VIR_NETDEV_MACVLAN_MODE_PASSTHRU] = MACVLAN_MODE_PASSTHRU,
|
|
|
|
};
|
|
|
|
|
2012-02-22 13:17:14 +00:00
|
|
|
/* Struct to hold the state and configuration of a 802.1qbg port */
|
|
|
|
struct virNetlinkCallbackData {
|
|
|
|
char *cr_ifname;
|
2021-03-11 07:16:13 +00:00
|
|
|
virNetDevVPortProfile *virtPortProfile;
|
2012-07-17 12:07:59 +00:00
|
|
|
virMacAddr macaddress;
|
2012-02-22 13:17:14 +00:00
|
|
|
char *linkdev;
|
2012-03-06 01:12:39 +00:00
|
|
|
int vf;
|
2012-04-25 11:55:07 +00:00
|
|
|
unsigned char vmuuid[VIR_UUID_BUFLEN];
|
2014-04-27 00:15:22 +00:00
|
|
|
virNetDevVPortProfileOp vmOp;
|
2012-02-22 13:17:14 +00:00
|
|
|
unsigned int linkState;
|
|
|
|
};
|
|
|
|
|
|
|
|
# define INSTANCE_STRLEN 36
|
|
|
|
|
|
|
|
static int instance2str(const unsigned char *p, char *dst, size_t size)
|
|
|
|
{
|
|
|
|
if (dst && size > INSTANCE_STRLEN) {
|
2019-11-13 13:53:42 +00:00
|
|
|
g_snprintf(dst, size, "%02x%02x%02x%02x-%02x%02x-%02x%02x-"
|
|
|
|
"%02x%02x-%02x%02x%02x%02x%02x%02x",
|
|
|
|
p[0], p[1], p[2], p[3],
|
|
|
|
p[4], p[5], p[6], p[7],
|
|
|
|
p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]);
|
2012-02-22 13:17:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
# define LLDPAD_PID_FILE "/var/run/lldpad.pid"
|
|
|
|
# define VIRIP_PID_FILE "/var/run/virip.pid"
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNetDevMacVLanVPortProfileCallback:
|
|
|
|
*
|
2013-04-03 13:09:19 +00:00
|
|
|
* @hdr: The buffer containing the received netlink header + payload
|
2012-02-22 13:17:14 +00:00
|
|
|
* @length: The length of the received netlink message.
|
|
|
|
* @peer: The netling sockaddr containing the peer information
|
|
|
|
* @handled: Contains information if the message has been replied to yet
|
|
|
|
* @opaque: Contains vital information regarding the associated vm an interface
|
|
|
|
*
|
|
|
|
* This function is called when a netlink message is received. The function
|
|
|
|
* reads the message and responds if it is pertinent to the running VMs
|
|
|
|
* network interface.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
2013-04-03 13:09:19 +00:00
|
|
|
virNetDevMacVLanVPortProfileCallback(struct nlmsghdr *hdr,
|
|
|
|
unsigned int length,
|
2012-02-22 13:17:14 +00:00
|
|
|
struct sockaddr_nl *peer,
|
|
|
|
bool *handled,
|
|
|
|
void *opaque)
|
|
|
|
{
|
2018-09-13 08:55:20 +00:00
|
|
|
struct nla_policy ifla_vf_policy[IFLA_VF_MAX + 1] = {
|
|
|
|
[IFLA_VF_MAC] = {.minlen = sizeof(struct ifla_vf_mac),
|
|
|
|
.maxlen = sizeof(struct ifla_vf_mac)},
|
|
|
|
[IFLA_VF_VLAN] = {.minlen = sizeof(struct ifla_vf_vlan),
|
|
|
|
.maxlen = sizeof(struct ifla_vf_vlan)},
|
2012-02-22 13:17:14 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct nla_policy ifla_port_policy[IFLA_PORT_MAX + 1] = {
|
|
|
|
[IFLA_PORT_RESPONSE] = {.type = NLA_U16},
|
|
|
|
};
|
|
|
|
|
|
|
|
struct nlattr *tb[IFLA_MAX + 1], *tb3[IFLA_PORT_MAX + 1],
|
|
|
|
*tb_vfinfo[IFLA_VF_MAX + 1], *tb_vfinfo_list;
|
|
|
|
|
|
|
|
struct ifinfomsg ifinfo;
|
|
|
|
void *data;
|
|
|
|
int rem;
|
|
|
|
char *ifname;
|
|
|
|
bool indicate = false;
|
2021-03-11 07:16:13 +00:00
|
|
|
struct virNetlinkCallbackData *calld = opaque;
|
2012-02-22 13:17:14 +00:00
|
|
|
pid_t lldpad_pid = 0;
|
|
|
|
pid_t virip_pid = 0;
|
2013-03-26 11:21:33 +00:00
|
|
|
char macaddr[VIR_MAC_STRING_BUFLEN];
|
2012-02-22 13:17:14 +00:00
|
|
|
|
|
|
|
data = nlmsg_data(hdr);
|
|
|
|
|
|
|
|
/* Quickly decide if we want this or not */
|
|
|
|
|
|
|
|
if (virPidFileReadPath(LLDPAD_PID_FILE, &lldpad_pid) < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ignore_value(virPidFileReadPath(VIRIP_PID_FILE, &virip_pid));
|
|
|
|
|
|
|
|
if (hdr->nlmsg_pid != lldpad_pid && hdr->nlmsg_pid != virip_pid)
|
|
|
|
return; /* we only care for lldpad and virip messages */
|
|
|
|
if (hdr->nlmsg_type != RTM_SETLINK)
|
|
|
|
return; /* we only care for RTM_SETLINK */
|
|
|
|
if (*handled)
|
|
|
|
return; /* if it has been handled - dont handle again */
|
|
|
|
|
|
|
|
/* DEBUG start */
|
|
|
|
VIR_INFO("netlink message nl_sockaddr: %p len: %d", peer, length);
|
|
|
|
VIR_DEBUG("nlmsg_type = 0x%02x", hdr->nlmsg_type);
|
|
|
|
VIR_DEBUG("nlmsg_len = 0x%04x", hdr->nlmsg_len);
|
|
|
|
VIR_DEBUG("nlmsg_pid = %d", hdr->nlmsg_pid);
|
|
|
|
VIR_DEBUG("nlmsg_seq = 0x%08x", hdr->nlmsg_seq);
|
|
|
|
VIR_DEBUG("nlmsg_flags = 0x%04x", hdr->nlmsg_flags);
|
|
|
|
|
|
|
|
VIR_DEBUG("lldpad pid = %d", lldpad_pid);
|
|
|
|
|
|
|
|
switch (hdr->nlmsg_type) {
|
|
|
|
case RTM_NEWLINK:
|
|
|
|
case RTM_DELLINK:
|
|
|
|
case RTM_SETLINK:
|
|
|
|
case RTM_GETLINK:
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG(" IFINFOMSG");
|
|
|
|
VIR_DEBUG(" ifi_family = 0x%02x",
|
2018-09-19 08:38:14 +00:00
|
|
|
((struct ifinfomsg *)data)->ifi_family);
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG(" ifi_type = 0x%x",
|
2018-09-19 08:38:14 +00:00
|
|
|
((struct ifinfomsg *)data)->ifi_type);
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG(" ifi_index = %i",
|
2018-09-19 08:38:14 +00:00
|
|
|
((struct ifinfomsg *)data)->ifi_index);
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG(" ifi_flags = 0x%04x",
|
2018-09-19 08:38:14 +00:00
|
|
|
((struct ifinfomsg *)data)->ifi_flags);
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG(" ifi_change = 0x%04x",
|
2018-09-19 08:38:14 +00:00
|
|
|
((struct ifinfomsg *)data)->ifi_change);
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
|
|
|
/* DEBUG end */
|
|
|
|
|
|
|
|
/* Parse netlink message assume a setlink with vfports */
|
2012-03-29 09:52:04 +00:00
|
|
|
memcpy(&ifinfo, NLMSG_DATA(hdr), sizeof(ifinfo));
|
2012-02-22 13:17:14 +00:00
|
|
|
VIR_DEBUG("family:%#x type:%#x index:%d flags:%#x change:%#x",
|
2018-09-19 08:38:14 +00:00
|
|
|
ifinfo.ifi_family, ifinfo.ifi_type, ifinfo.ifi_index,
|
|
|
|
ifinfo.ifi_flags, ifinfo.ifi_change);
|
2012-03-29 09:52:04 +00:00
|
|
|
if (nlmsg_parse(hdr, sizeof(ifinfo),
|
2018-09-19 08:38:14 +00:00
|
|
|
(struct nlattr **)&tb, IFLA_MAX, NULL)) {
|
2012-02-22 13:17:14 +00:00
|
|
|
VIR_DEBUG("error parsing request...");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb[IFLA_VFINFO_LIST]) {
|
|
|
|
VIR_DEBUG("FOUND IFLA_VFINFO_LIST!");
|
|
|
|
|
|
|
|
nla_for_each_nested(tb_vfinfo_list, tb[IFLA_VFINFO_LIST], rem) {
|
|
|
|
if (nla_type(tb_vfinfo_list) != IFLA_VF_INFO) {
|
|
|
|
VIR_DEBUG("nested parsing of"
|
2018-09-19 08:38:14 +00:00
|
|
|
"IFLA_VFINFO_LIST failed.");
|
2012-02-22 13:17:14 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (nla_parse_nested(tb_vfinfo, IFLA_VF_MAX,
|
2018-09-19 08:38:14 +00:00
|
|
|
tb_vfinfo_list, ifla_vf_policy)) {
|
2012-02-22 13:17:14 +00:00
|
|
|
VIR_DEBUG("nested parsing of "
|
2018-09-19 08:38:14 +00:00
|
|
|
"IFLA_VF_INFO failed.");
|
2012-02-22 13:17:14 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb_vfinfo[IFLA_VF_MAC]) {
|
|
|
|
struct ifla_vf_mac *mac = RTA_DATA(tb_vfinfo[IFLA_VF_MAC]);
|
|
|
|
unsigned char *m = mac->mac;
|
|
|
|
|
|
|
|
VIR_DEBUG("IFLA_VF_MAC = %2x:%2x:%2x:%2x:%2x:%2x",
|
|
|
|
m[0], m[1], m[2], m[3], m[4], m[5]);
|
|
|
|
|
2014-09-03 22:24:43 +00:00
|
|
|
if (virMacAddrCmpRaw(&calld->macaddress, mac->mac)) {
|
2012-02-22 13:17:14 +00:00
|
|
|
/* Repeat the same check for a broadcast mac */
|
Convert 'int i' to 'size_t i' in src/util/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i;
|
2012-02-22 13:17:14 +00:00
|
|
|
|
2012-07-17 12:07:59 +00:00
|
|
|
for (i = 0; i < VIR_MAC_BUFLEN; i++) {
|
|
|
|
if (calld->macaddress.addr[i] != 0xff) {
|
2012-02-22 13:17:14 +00:00
|
|
|
VIR_DEBUG("MAC address match failed (wasn't broadcast)");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb_vfinfo[IFLA_VF_VLAN]) {
|
|
|
|
struct ifla_vf_vlan *vlan = RTA_DATA(tb_vfinfo[IFLA_VF_VLAN]);
|
|
|
|
|
|
|
|
VIR_DEBUG("IFLA_VF_VLAN = %d", vlan->vlan);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb[IFLA_IFNAME]) {
|
|
|
|
ifname = (char *)RTA_DATA(tb[IFLA_IFNAME]);
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("IFLA_IFNAME = %s", ifname);
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (tb[IFLA_OPERSTATE]) {
|
|
|
|
rem = *(unsigned short *)RTA_DATA(tb[IFLA_OPERSTATE]);
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("IFLA_OPERSTATE = %d", rem);
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (tb[IFLA_VF_PORTS]) {
|
|
|
|
struct nlattr *tb_vf_ports;
|
|
|
|
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("found IFLA_VF_PORTS");
|
2012-02-22 13:17:14 +00:00
|
|
|
nla_for_each_nested(tb_vf_ports, tb[IFLA_VF_PORTS], rem) {
|
|
|
|
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("iterating");
|
2012-02-22 13:17:14 +00:00
|
|
|
if (nla_type(tb_vf_ports) != IFLA_VF_PORT) {
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("not a IFLA_VF_PORT. skipping");
|
2012-02-22 13:17:14 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (nla_parse_nested(tb3, IFLA_PORT_MAX, tb_vf_ports,
|
2018-09-19 08:38:14 +00:00
|
|
|
ifla_port_policy)) {
|
2012-02-22 13:17:14 +00:00
|
|
|
VIR_DEBUG("nested parsing on level 2"
|
|
|
|
" failed.");
|
|
|
|
}
|
|
|
|
if (tb3[IFLA_PORT_VF]) {
|
|
|
|
VIR_DEBUG("IFLA_PORT_VF = %d",
|
|
|
|
*(uint32_t *) (RTA_DATA(tb3[IFLA_PORT_VF])));
|
|
|
|
}
|
|
|
|
if (tb3[IFLA_PORT_PROFILE]) {
|
|
|
|
VIR_DEBUG("IFLA_PORT_PROFILE = %s",
|
|
|
|
(char *) RTA_DATA(tb3[IFLA_PORT_PROFILE]));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb3[IFLA_PORT_VSI_TYPE]) {
|
|
|
|
struct ifla_port_vsi *pvsi;
|
|
|
|
int tid = 0;
|
|
|
|
|
|
|
|
pvsi = (struct ifla_port_vsi *)
|
|
|
|
RTA_DATA(tb3[IFLA_PORT_VSI_TYPE]);
|
|
|
|
tid = ((pvsi->vsi_type_id[2] << 16) |
|
|
|
|
(pvsi->vsi_type_id[1] << 8) |
|
|
|
|
pvsi->vsi_type_id[0]);
|
|
|
|
|
|
|
|
VIR_DEBUG("mgr_id: %d", pvsi->vsi_mgr_id);
|
|
|
|
VIR_DEBUG("type_id: %d", tid);
|
|
|
|
VIR_DEBUG("type_version: %d",
|
|
|
|
pvsi->vsi_type_version);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb3[IFLA_PORT_INSTANCE_UUID]) {
|
|
|
|
char instance[INSTANCE_STRLEN + 2];
|
|
|
|
unsigned char *uuid;
|
|
|
|
|
|
|
|
uuid = (unsigned char *)
|
|
|
|
RTA_DATA(tb3[IFLA_PORT_INSTANCE_UUID]);
|
|
|
|
instance2str(uuid, instance, sizeof(instance));
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("IFLA_PORT_INSTANCE_UUID = %s",
|
2012-02-22 13:17:14 +00:00
|
|
|
instance);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb3[IFLA_PORT_REQUEST]) {
|
|
|
|
uint8_t req = *(uint8_t *) RTA_DATA(tb3[IFLA_PORT_REQUEST]);
|
|
|
|
VIR_DEBUG("IFLA_PORT_REQUEST = %d", req);
|
|
|
|
|
|
|
|
if (req == PORT_REQUEST_DISASSOCIATE) {
|
2018-12-04 17:08:14 +00:00
|
|
|
VIR_DEBUG("Set disassociated.");
|
2012-02-22 13:17:14 +00:00
|
|
|
indicate = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tb3[IFLA_PORT_RESPONSE]) {
|
2018-09-19 08:38:14 +00:00
|
|
|
VIR_DEBUG("IFLA_PORT_RESPONSE = %d",
|
|
|
|
*(uint16_t *) RTA_DATA(tb3[IFLA_PORT_RESPONSE]));
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-11-13 14:28:18 +00:00
|
|
|
if (!indicate)
|
2012-02-22 13:17:14 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
VIR_INFO("Re-send 802.1qbg associate request:");
|
|
|
|
VIR_INFO(" if: %s", calld->cr_ifname);
|
|
|
|
VIR_INFO(" lf: %s", calld->linkdev);
|
2013-03-26 11:21:33 +00:00
|
|
|
VIR_INFO(" mac: %s", virMacAddrFormat(&calld->macaddress, macaddr));
|
2012-02-22 13:17:14 +00:00
|
|
|
ignore_value(virNetDevVPortProfileAssociate(calld->cr_ifname,
|
|
|
|
calld->virtPortProfile,
|
2012-07-17 12:07:59 +00:00
|
|
|
&calld->macaddress,
|
2012-02-22 13:17:14 +00:00
|
|
|
calld->linkdev,
|
2012-03-06 01:12:39 +00:00
|
|
|
calld->vf,
|
2012-02-22 13:17:14 +00:00
|
|
|
calld->vmuuid,
|
|
|
|
calld->vmOp, true));
|
|
|
|
*handled = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNetlinkCallbackDataFree
|
|
|
|
*
|
|
|
|
* @calld: pointer to a virNetlinkCallbackData object to free
|
|
|
|
*
|
|
|
|
* This function frees all the data associated with a virNetlinkCallbackData object
|
|
|
|
* as well as the object itself. If called with NULL, it does nothing.
|
|
|
|
*
|
|
|
|
* Returns nothing.
|
|
|
|
*/
|
|
|
|
static void
|
2021-03-11 07:16:13 +00:00
|
|
|
virNetlinkCallbackDataFree(struct virNetlinkCallbackData *calld)
|
2012-02-22 13:17:14 +00:00
|
|
|
{
|
|
|
|
if (calld) {
|
2021-02-03 19:32:34 +00:00
|
|
|
g_free(calld->cr_ifname);
|
|
|
|
g_free(calld->virtPortProfile);
|
|
|
|
g_free(calld->linkdev);
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
2021-02-03 19:32:34 +00:00
|
|
|
g_free(calld);
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNetDevMacVLanVPortProfileDestroyCallback:
|
|
|
|
*
|
|
|
|
* @watch: watch whose handle to remove
|
|
|
|
* @macaddr: macaddr whose handle to remove
|
|
|
|
* @opaque: Contains vital information regarding the associated vm
|
|
|
|
*
|
|
|
|
* This function is called when a netlink message handler is terminated.
|
|
|
|
* The function frees locally allocated data referenced in the opaque
|
|
|
|
* data, and the opaque object itself.
|
|
|
|
*/
|
|
|
|
static void
|
2019-10-14 12:45:33 +00:00
|
|
|
virNetDevMacVLanVPortProfileDestroyCallback(int watch G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddr G_GNUC_UNUSED,
|
2012-02-22 13:17:14 +00:00
|
|
|
void *opaque)
|
|
|
|
{
|
2021-03-11 07:16:13 +00:00
|
|
|
virNetlinkCallbackDataFree((struct virNetlinkCallbackData *)opaque);
|
2012-02-22 13:17:14 +00:00
|
|
|
}
|
|
|
|
|
2012-03-29 11:15:00 +00:00
|
|
|
int
|
2012-03-27 12:38:33 +00:00
|
|
|
virNetDevMacVLanVPortProfileRegisterCallback(const char *ifname,
|
2013-10-05 19:41:44 +00:00
|
|
|
const virMacAddr *macaddress,
|
2012-03-27 12:38:33 +00:00
|
|
|
const char *linkdev,
|
|
|
|
const unsigned char *vmuuid,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile,
|
2014-04-27 00:15:22 +00:00
|
|
|
virNetDevVPortProfileOp vmOp)
|
2012-03-27 12:38:33 +00:00
|
|
|
{
|
2021-03-11 07:16:13 +00:00
|
|
|
struct virNetlinkCallbackData *calld = NULL;
|
2012-03-27 12:38:33 +00:00
|
|
|
|
2012-08-22 04:10:23 +00:00
|
|
|
if (virtPortProfile && virNetlinkEventServiceIsRunning(NETLINK_ROUTE)) {
|
2020-10-05 17:08:12 +00:00
|
|
|
calld = g_new0(struct virNetlinkCallbackData, 1);
|
2019-10-20 11:49:46 +00:00
|
|
|
calld->cr_ifname = g_strdup(ifname);
|
2020-10-05 17:08:12 +00:00
|
|
|
calld->virtPortProfile = g_new0(virNetDevVPortProfile, 1);
|
2012-03-27 12:38:33 +00:00
|
|
|
memcpy(calld->virtPortProfile, virtPortProfile, sizeof(*virtPortProfile));
|
2012-07-17 12:07:59 +00:00
|
|
|
virMacAddrSet(&calld->macaddress, macaddress);
|
2019-10-20 11:49:46 +00:00
|
|
|
calld->linkdev = g_strdup(linkdev);
|
2012-04-25 11:55:07 +00:00
|
|
|
memcpy(calld->vmuuid, vmuuid, sizeof(calld->vmuuid));
|
2012-03-27 12:38:33 +00:00
|
|
|
|
|
|
|
calld->vmOp = vmOp;
|
|
|
|
|
|
|
|
if (virNetlinkEventAddClient(virNetDevMacVLanVPortProfileCallback,
|
|
|
|
virNetDevMacVLanVPortProfileDestroyCallback,
|
2012-08-22 04:10:23 +00:00
|
|
|
calld, macaddress, NETLINK_ROUTE) < 0)
|
2012-03-27 12:38:33 +00:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2014-03-25 06:53:22 +00:00
|
|
|
error:
|
2012-03-27 12:38:33 +00:00
|
|
|
virNetlinkCallbackDataFree(calld);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2012-02-22 13:17:14 +00:00
|
|
|
|
2011-11-02 17:11:02 +00:00
|
|
|
/**
|
2011-11-02 17:19:48 +00:00
|
|
|
* virNetDevMacVLanCreateWithVPortProfile:
|
2011-11-02 17:11:02 +00:00
|
|
|
* Create an instance of a macvtap device and open its tap character
|
|
|
|
* device.
|
2016-01-19 19:20:54 +00:00
|
|
|
|
|
|
|
* @ifnameRequested: Interface name that the caller wants the macvtap
|
|
|
|
* device to have, or NULL to pick the first available name
|
|
|
|
* appropriate for the type (macvlan%d or macvtap%d). If the
|
|
|
|
* suggested name fits one of those patterns, but is already in
|
|
|
|
* use, we will fallback to finding the first available. If the
|
|
|
|
* suggested name *doesn't* fit a pattern and the name is in use,
|
|
|
|
* we will fail.
|
2011-11-02 17:11:02 +00:00
|
|
|
* @macaddress: The MAC address for the macvtap device
|
|
|
|
* @linkdev: The interface name of the NIC to connect to the external bridge
|
2016-01-19 19:20:54 +00:00
|
|
|
* @mode: macvtap mode (VIR_NETDEV_MACVLAN_MODE_(BRIDGE|VEPA|PRIVATE|PASSTHRU)
|
2011-11-02 17:11:02 +00:00
|
|
|
* @vmuuid: The UUID of the VM the macvtap belongs to
|
|
|
|
* @virtPortProfile: pointer to object holding the virtual port profile data
|
2016-01-19 19:20:54 +00:00
|
|
|
* @ifnameResult: Pointer to a string pointer where the actual name of the
|
2011-11-02 17:11:02 +00:00
|
|
|
* interface will be stored into if everything succeeded. It is up
|
|
|
|
* to the caller to free the string.
|
2015-12-04 10:31:17 +00:00
|
|
|
* @tapfd: array of file descriptor return value for the new tap device
|
|
|
|
* @tapfdSize: number of file descriptors in @tapfd
|
2014-08-27 14:34:13 +00:00
|
|
|
* @flags: OR of virNetDevMacVLanCreateFlags.
|
2011-11-02 17:11:02 +00:00
|
|
|
*
|
2015-12-04 10:31:17 +00:00
|
|
|
* Creates a macvlan device. Optionally, if flags &
|
|
|
|
* VIR_NETDEV_MACVLAN_CREATE_WITH_TAP is set, @tapfd is populated with FDs of
|
|
|
|
* tap devices up to @tapfdSize.
|
|
|
|
*
|
|
|
|
* Return 0 on success, -1 on error.
|
2011-11-02 17:11:02 +00:00
|
|
|
*/
|
2016-01-19 19:20:54 +00:00
|
|
|
int
|
|
|
|
virNetDevMacVLanCreateWithVPortProfile(const char *ifnameRequested,
|
|
|
|
const virMacAddr *macaddress,
|
|
|
|
const char *linkdev,
|
|
|
|
virNetDevMacVLanMode mode,
|
2019-10-01 16:25:47 +00:00
|
|
|
const virNetDevVlan *vlan,
|
2016-01-19 19:20:54 +00:00
|
|
|
const unsigned char *vmuuid,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile,
|
2016-01-19 19:20:54 +00:00
|
|
|
char **ifnameResult,
|
|
|
|
virNetDevVPortProfileOp vmOp,
|
|
|
|
char *stateDir,
|
|
|
|
int *tapfd,
|
|
|
|
size_t tapfdSize,
|
|
|
|
unsigned int flags)
|
2011-11-02 17:11:02 +00:00
|
|
|
{
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
g_autofree char *ifname = NULL;
|
2011-11-02 17:11:02 +00:00
|
|
|
uint32_t macvtapMode;
|
2012-03-06 01:12:39 +00:00
|
|
|
int vf = -1;
|
2015-12-03 10:33:55 +00:00
|
|
|
bool vnet_hdr = flags & VIR_NETDEV_MACVLAN_VNET_HDR;
|
2020-12-15 19:50:40 +00:00
|
|
|
virNetDevGenNameType type;
|
2011-11-02 17:11:02 +00:00
|
|
|
|
|
|
|
macvtapMode = modeMap[mode];
|
|
|
|
|
2016-01-19 19:20:54 +00:00
|
|
|
*ifnameResult = NULL;
|
2011-11-02 17:11:02 +00:00
|
|
|
|
|
|
|
/** Note: When using PASSTHROUGH mode with MACVTAP devices the link
|
|
|
|
* device's MAC address must be set to the VMs MAC address. In
|
|
|
|
* order to not confuse the first switch or bridge in line this MAC
|
|
|
|
* address must be reset when the VM is shut down.
|
|
|
|
* This is especially important when using SRIOV capable cards that
|
|
|
|
* emulate their switch in firmware.
|
|
|
|
*/
|
2015-08-26 04:18:26 +00:00
|
|
|
|
2011-11-02 17:11:02 +00:00
|
|
|
if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) {
|
2017-03-05 22:43:39 +00:00
|
|
|
bool setVlan = true;
|
|
|
|
|
2015-08-26 04:18:26 +00:00
|
|
|
if (virtPortProfile &&
|
|
|
|
virtPortProfile->virtPortType == VIR_NETDEV_VPORT_PROFILE_8021QBH) {
|
2017-03-05 22:43:39 +00:00
|
|
|
/* The Cisco enic driver (the only SRIOV-capable card that
|
|
|
|
* uses 802.1Qbh) doesn't support IFLA_VFINFO_LIST, which
|
|
|
|
* is required to get/set the vlan tag of a VF.
|
2015-08-26 04:18:26 +00:00
|
|
|
*/
|
2017-03-05 22:43:39 +00:00
|
|
|
setVlan = false;
|
2015-08-26 04:18:26 +00:00
|
|
|
}
|
2017-03-05 22:43:39 +00:00
|
|
|
|
|
|
|
if (virNetDevSaveNetConfig(linkdev, -1, stateDir, setVlan) < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (virNetDevSetNetConfig(linkdev, -1, NULL, vlan, macaddress, setVlan) < 0)
|
|
|
|
return -1;
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
|
2016-01-19 19:20:54 +00:00
|
|
|
if (ifnameRequested) {
|
|
|
|
VIR_INFO("Requested macvtap device name: %s", ifnameRequested);
|
2020-12-15 19:50:40 +00:00
|
|
|
ifname = g_strdup(ifnameRequested);
|
2016-01-19 19:20:54 +00:00
|
|
|
}
|
|
|
|
|
2020-12-15 19:50:40 +00:00
|
|
|
if (flags & VIR_NETDEV_MACVLAN_CREATE_WITH_TAP)
|
|
|
|
type = VIR_NET_DEV_GEN_NAME_MACVTAP;
|
|
|
|
else
|
|
|
|
type = VIR_NET_DEV_GEN_NAME_MACVLAN;
|
2020-12-14 01:50:34 +00:00
|
|
|
|
2020-12-15 19:50:40 +00:00
|
|
|
if (virNetDevGenerateName(&ifname, type) < 0 ||
|
|
|
|
virNetDevMacVLanCreate(ifname, macaddress,
|
|
|
|
linkdev, macvtapMode, flags) < 0) {
|
|
|
|
return -1;
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
if (virNetDevVPortProfileAssociate(ifname,
|
2011-11-02 17:11:02 +00:00
|
|
|
virtPortProfile,
|
|
|
|
macaddress,
|
|
|
|
linkdev,
|
2012-03-06 01:12:39 +00:00
|
|
|
vf,
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
vmuuid, vmOp, false) < 0) {
|
2011-11-02 17:11:02 +00:00
|
|
|
goto link_del_exit;
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
}
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2014-09-16 20:50:53 +00:00
|
|
|
if (flags & VIR_NETDEV_MACVLAN_CREATE_IFUP) {
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
if (virNetDevSetOnline(ifname, true) < 0)
|
2014-09-16 20:50:53 +00:00
|
|
|
goto disassociate_exit;
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
|
2014-08-27 14:34:13 +00:00
|
|
|
if (flags & VIR_NETDEV_MACVLAN_CREATE_WITH_TAP) {
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
if (virNetDevMacVLanTapOpen(ifname, tapfd, tapfdSize) < 0)
|
2011-11-10 10:29:09 +00:00
|
|
|
goto disassociate_exit;
|
|
|
|
|
2016-08-09 17:23:15 +00:00
|
|
|
if (virNetDevMacVLanTapSetup(tapfd, tapfdSize, vnet_hdr) < 0)
|
2011-11-02 17:11:02 +00:00
|
|
|
goto disassociate_exit;
|
2011-11-10 10:29:09 +00:00
|
|
|
}
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2012-04-13 12:41:16 +00:00
|
|
|
if (vmOp == VIR_NETDEV_VPORT_PROFILE_OP_CREATE ||
|
|
|
|
vmOp == VIR_NETDEV_VPORT_PROFILE_OP_RESTORE) {
|
|
|
|
/* Only directly register upon a create or restore (restarting
|
|
|
|
* a saved image) - migration and libvirtd restart are handled
|
|
|
|
* elsewhere.
|
|
|
|
*/
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
if (virNetDevMacVLanVPortProfileRegisterCallback(ifname, macaddress,
|
2012-04-13 12:41:16 +00:00
|
|
|
linkdev, vmuuid,
|
|
|
|
virtPortProfile,
|
2012-10-17 09:23:12 +00:00
|
|
|
vmOp) < 0)
|
2016-08-09 17:23:15 +00:00
|
|
|
goto disassociate_exit;
|
2012-04-13 12:41:16 +00:00
|
|
|
}
|
2011-11-02 17:11:02 +00:00
|
|
|
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
*ifnameResult = g_steal_pointer(&ifname);
|
2016-08-09 17:23:15 +00:00
|
|
|
return 0;
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2014-03-25 06:53:22 +00:00
|
|
|
disassociate_exit:
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
ignore_value(virNetDevVPortProfileDisassociate(ifname,
|
2011-11-02 17:11:02 +00:00
|
|
|
virtPortProfile,
|
|
|
|
macaddress,
|
|
|
|
linkdev,
|
2012-03-06 01:12:39 +00:00
|
|
|
vf,
|
2011-11-02 17:11:02 +00:00
|
|
|
vmOp));
|
2015-12-04 10:31:17 +00:00
|
|
|
while (tapfdSize--)
|
|
|
|
VIR_FORCE_CLOSE(tapfd[tapfdSize]);
|
2011-11-02 17:11:02 +00:00
|
|
|
|
2014-03-25 06:53:22 +00:00
|
|
|
link_del_exit:
|
util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.
In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).
A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)
But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.
This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-23 18:57:19 +00:00
|
|
|
ignore_value(virNetDevMacVLanDelete(ifname));
|
2016-08-09 17:23:15 +00:00
|
|
|
return -1;
|
2011-11-02 17:11:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2011-11-02 17:19:48 +00:00
|
|
|
* virNetDevMacVLanDeleteWithVPortProfile:
|
2011-11-02 17:11:02 +00:00
|
|
|
* @ifname : The name of the macvtap interface
|
|
|
|
* @linkdev: The interface name of the NIC to connect to the external bridge
|
|
|
|
* @virtPortProfile: pointer to object holding the virtual port profile data
|
|
|
|
*
|
|
|
|
* Delete an interface given its name. Disassociate
|
|
|
|
* it with the switch if port profile parameters
|
|
|
|
* were provided.
|
|
|
|
*/
|
2011-11-02 17:19:48 +00:00
|
|
|
int virNetDevMacVLanDeleteWithVPortProfile(const char *ifname,
|
2013-10-05 19:41:44 +00:00
|
|
|
const virMacAddr *macaddr,
|
2011-11-02 17:19:48 +00:00
|
|
|
const char *linkdev,
|
|
|
|
int mode,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile,
|
2011-11-02 17:19:48 +00:00
|
|
|
char *stateDir)
|
2011-11-02 17:11:02 +00:00
|
|
|
{
|
|
|
|
int ret = 0;
|
2012-03-06 01:12:39 +00:00
|
|
|
|
2011-11-02 17:11:02 +00:00
|
|
|
if (ifname) {
|
|
|
|
if (virNetDevVPortProfileDisassociate(ifname,
|
|
|
|
virtPortProfile,
|
|
|
|
macaddr,
|
|
|
|
linkdev,
|
2017-03-05 22:32:15 +00:00
|
|
|
-1,
|
2011-11-02 17:11:02 +00:00
|
|
|
VIR_NETDEV_VPORT_PROFILE_OP_DESTROY) < 0)
|
|
|
|
ret = -1;
|
2011-11-02 17:26:11 +00:00
|
|
|
if (virNetDevMacVLanDelete(ifname) < 0)
|
2011-11-02 17:11:02 +00:00
|
|
|
ret = -1;
|
|
|
|
}
|
2012-02-22 13:17:14 +00:00
|
|
|
|
2016-01-21 19:19:56 +00:00
|
|
|
if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) {
|
2019-10-15 12:47:50 +00:00
|
|
|
g_autoptr(virMacAddr) MAC = NULL;
|
|
|
|
g_autoptr(virMacAddr) adminMAC = NULL;
|
|
|
|
g_autoptr(virNetDevVlan) vlan = NULL;
|
2017-03-05 22:43:39 +00:00
|
|
|
|
util: restructure virNetDevReadNetConfig() to eliminate false error logs
virHostdevRestoreNetConfig() calls virNetDevReadNetConfig() to try and
read the "original config" of a netdev, and if that fails, it tries
again with a different directory/netdev name. This achieves the
desired effect (we end up finding the config wherever it may be), but
for each failure, virNetDevReadNetConfig() places a nice error message
in the system logs. Experience has shown that false-positive error
logs like this lead to erroneous bug reports, and can often mislead
those searching for *real* bugs.
This patch changes virNetDevReadNetConfig() to explicitly check if the
file exists before calling virFileReadAll(); if it doesn't exist,
virNetDevReadNetConfig() returns a success, but leaves all the
variables holding the results as NULL. (This makes sense if you define
the purpose of the function as "read a netdev's config from its config
file *if that file exists*).
To take advantage of that change, the caller,
virHostdevRestoreNetConfig() is modified to fail immediately if
virNetDevReadNetConfig() returns an error, and otherwise to try the
different directory/netdev name if adminMAC & vlan & MAC are all NULL
after the preceding attempt.
2017-08-10 00:49:26 +00:00
|
|
|
if ((virNetDevReadNetConfig(linkdev, -1, stateDir,
|
|
|
|
&adminMAC, &vlan, &MAC) == 0) &&
|
2018-09-19 08:38:14 +00:00
|
|
|
(adminMAC || vlan || MAC)) {
|
2017-03-05 22:43:39 +00:00
|
|
|
|
|
|
|
ignore_value(virNetDevSetNetConfig(linkdev, -1,
|
|
|
|
adminMAC, vlan, MAC, !!vlan));
|
|
|
|
}
|
2016-01-21 19:19:56 +00:00
|
|
|
}
|
|
|
|
|
2012-08-22 04:10:23 +00:00
|
|
|
virNetlinkEventRemoveClient(0, macaddr, NETLINK_ROUTE);
|
2012-02-22 13:17:14 +00:00
|
|
|
|
2011-11-02 17:11:02 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-03-27 12:38:33 +00:00
|
|
|
/**
|
|
|
|
* virNetDevMacVLanRestartWithVPortProfile:
|
|
|
|
* Register a port profile callback handler for a VM that
|
|
|
|
* is already running
|
|
|
|
* .
|
|
|
|
* @cr_ifname: Interface name that the macvtap has.
|
|
|
|
* @macaddress: The MAC address for the macvtap device
|
|
|
|
* @linkdev: The interface name of the NIC to connect to the external bridge
|
|
|
|
* @vmuuid: The UUID of the VM the macvtap belongs to
|
|
|
|
* @virtPortProfile: pointer to object holding the virtual port profile data
|
|
|
|
* @vmOp: Operation to use during setup of the association
|
|
|
|
*
|
|
|
|
* Returns 0; returns -1 on error.
|
|
|
|
*/
|
|
|
|
int virNetDevMacVLanRestartWithVPortProfile(const char *cr_ifname,
|
2017-02-10 14:35:23 +00:00
|
|
|
const virMacAddr *macaddress,
|
|
|
|
const char *linkdev,
|
|
|
|
const unsigned char *vmuuid,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile,
|
2017-02-10 14:35:23 +00:00
|
|
|
virNetDevVPortProfileOp vmOp)
|
2012-03-27 12:38:33 +00:00
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
rc = virNetDevMacVLanVPortProfileRegisterCallback(cr_ifname, macaddress,
|
|
|
|
linkdev, vmuuid,
|
|
|
|
virtPortProfile, vmOp);
|
|
|
|
if (rc < 0)
|
2020-01-06 21:57:45 +00:00
|
|
|
return rc;
|
2012-03-27 12:38:33 +00:00
|
|
|
|
|
|
|
ignore_value(virNetDevVPortProfileAssociate(cr_ifname,
|
|
|
|
virtPortProfile,
|
|
|
|
macaddress,
|
|
|
|
linkdev,
|
|
|
|
-1,
|
|
|
|
vmuuid,
|
|
|
|
vmOp, true));
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
build: eliminate WITH_MACVTAP flag entirely
This flag was originally created to indicate that either 1) the build
platform wasn't linux, 2) the build platform was linux, but the kernel
was too old to have macvtap support. Since there was already a switch
there, the ability to also disable it when 3) the kernel supports
macvtap but the user doesn't want it, was added in. I don't think that
(3) was ever an intentional goal, just something that grew naturally
out of having the flag there in the first place (unless possibly the
original author wanted a way to quickly disable their new code in case
it caused regressions elsewhere).
Now that the check for (2) has been removed, WITH_MACVTAP is just
checking (1) and (3), but (3) is pointless (because the extra code in
libvirt itself is miniscule, and the only external library needed for
it is libnl, which is also required for other unrelated features (and
itself has no subordinate dependencies and takes up < 1MB on
disk)). We can therfore eliminate the WITH_MACVTAP flag, as it is
functionally equivalent to WITH_LIBNL (which implies __linux__).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-29 14:54:38 +00:00
|
|
|
#else /* ! WITH_LIBNL */
|
2019-10-14 12:45:33 +00:00
|
|
|
bool virNetDevMacVLanIsMacvtap(const char *ifname G_GNUC_UNUSED)
|
2019-09-10 09:24:19 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-10-14 12:45:33 +00:00
|
|
|
int virNetDevMacVLanCreate(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddress G_GNUC_UNUSED,
|
|
|
|
const char *srcdev G_GNUC_UNUSED,
|
2020-12-14 01:50:34 +00:00
|
|
|
uint32_t macvlan_mode G_GNUC_UNUSED,
|
|
|
|
unsigned int fflags G_GNUC_UNUSED)
|
2011-11-02 17:34:41 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-10-14 12:45:33 +00:00
|
|
|
int virNetDevMacVLanDelete(const char *ifname G_GNUC_UNUSED)
|
2011-11-02 17:34:41 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-09-10 09:24:19 +00:00
|
|
|
int
|
2019-10-14 12:45:33 +00:00
|
|
|
virNetDevMacVLanTapOpen(const char *ifname G_GNUC_UNUSED,
|
|
|
|
int *tapfd G_GNUC_UNUSED,
|
|
|
|
size_t tapfdSize G_GNUC_UNUSED)
|
2019-09-10 09:24:19 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2019-10-14 12:45:33 +00:00
|
|
|
virNetDevMacVLanTapSetup(int *tapfd G_GNUC_UNUSED,
|
|
|
|
size_t tapfdSize G_GNUC_UNUSED,
|
|
|
|
bool vnet_hdr G_GNUC_UNUSED)
|
2019-09-10 09:24:19 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-10-14 12:45:33 +00:00
|
|
|
int virNetDevMacVLanCreateWithVPortProfile(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddress G_GNUC_UNUSED,
|
|
|
|
const char *linkdev G_GNUC_UNUSED,
|
|
|
|
virNetDevMacVLanMode mode G_GNUC_UNUSED,
|
2019-10-01 16:25:47 +00:00
|
|
|
const virNetDevVlan *vlan G_GNUC_UNUSED,
|
2019-10-14 12:45:33 +00:00
|
|
|
const unsigned char *vmuuid G_GNUC_UNUSED,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile G_GNUC_UNUSED,
|
2019-10-14 12:45:33 +00:00
|
|
|
char **res_ifname G_GNUC_UNUSED,
|
|
|
|
virNetDevVPortProfileOp vmop G_GNUC_UNUSED,
|
|
|
|
char *stateDir G_GNUC_UNUSED,
|
|
|
|
int *tapfd G_GNUC_UNUSED,
|
|
|
|
size_t tapfdSize G_GNUC_UNUSED,
|
|
|
|
unsigned int unused_flags G_GNUC_UNUSED)
|
2011-11-02 17:11:02 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-10-14 12:45:33 +00:00
|
|
|
int virNetDevMacVLanDeleteWithVPortProfile(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddress G_GNUC_UNUSED,
|
|
|
|
const char *linkdev G_GNUC_UNUSED,
|
|
|
|
int mode G_GNUC_UNUSED,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile G_GNUC_UNUSED,
|
2019-10-14 12:45:33 +00:00
|
|
|
char *stateDir G_GNUC_UNUSED)
|
2011-11-02 17:11:02 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
2012-03-27 12:38:33 +00:00
|
|
|
|
2019-10-14 12:45:33 +00:00
|
|
|
int virNetDevMacVLanRestartWithVPortProfile(const char *cr_ifname G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddress G_GNUC_UNUSED,
|
|
|
|
const char *linkdev G_GNUC_UNUSED,
|
|
|
|
const unsigned char *vmuuid G_GNUC_UNUSED,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile G_GNUC_UNUSED,
|
2019-10-14 12:45:33 +00:00
|
|
|
virNetDevVPortProfileOp vmOp G_GNUC_UNUSED)
|
2012-03-27 12:38:33 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
2012-03-29 11:15:00 +00:00
|
|
|
|
2019-10-14 12:45:33 +00:00
|
|
|
int virNetDevMacVLanVPortProfileRegisterCallback(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddress G_GNUC_UNUSED,
|
|
|
|
const char *linkdev G_GNUC_UNUSED,
|
|
|
|
const unsigned char *vmuuid G_GNUC_UNUSED,
|
2019-10-01 17:56:35 +00:00
|
|
|
const virNetDevVPortProfile *virtPortProfile G_GNUC_UNUSED,
|
2019-10-14 12:45:33 +00:00
|
|
|
virNetDevVPortProfileOp vmOp G_GNUC_UNUSED)
|
2012-03-29 11:15:00 +00:00
|
|
|
{
|
|
|
|
virReportSystemError(ENOSYS, "%s",
|
|
|
|
_("Cannot create macvlan devices on this platform"));
|
|
|
|
return -1;
|
|
|
|
}
|
build: eliminate WITH_MACVTAP flag entirely
This flag was originally created to indicate that either 1) the build
platform wasn't linux, 2) the build platform was linux, but the kernel
was too old to have macvtap support. Since there was already a switch
there, the ability to also disable it when 3) the kernel supports
macvtap but the user doesn't want it, was added in. I don't think that
(3) was ever an intentional goal, just something that grew naturally
out of having the flag there in the first place (unless possibly the
original author wanted a way to quickly disable their new code in case
it caused regressions elsewhere).
Now that the check for (2) has been removed, WITH_MACVTAP is just
checking (1) and (3), but (3) is pointless (because the extra code in
libvirt itself is miniscule, and the only external library needed for
it is libnl, which is also required for other unrelated features (and
itself has no subordinate dependencies and takes up < 1MB on
disk)). We can therfore eliminate the WITH_MACVTAP flag, as it is
functionally equivalent to WITH_LIBNL (which implies __linux__).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-29 14:54:38 +00:00
|
|
|
#endif /* ! WITH_LIBNL */
|