This resolves
https://bugzilla.redhat.com/1723367
It has become more popular to run libvirtd in an unprivileged
environment (e.g. inside a container), but until now the only possible
types of network connection for a qemu started by an unprivileged
libvirtd were:
1) a usermode slirp connection
2) a tap device connection to a bridge handled by running
qemu-bridge-helper (a suid-root utility distributed with qemu)
3) a host network card assigned to the guest using VFIO (this requires
special setup by a privileged process though)
This patch series remedies that by making it possible for libvirtd to
use a tap device that has been pre-created (*and* properly setup) by
some other process beforehand.
In order to use this, you must have a standard tap, or macvtap device
that has been set to be owned by the uid that will be running
libvirtd, has its MAC address already set, and has been set online
(IFF_UP). For example, here are the commands to create a standard tap
device named "mytap0", attach it to the host bridge device "br0" and
prepare it for use by a libvirtd that is running as user "laine":
ip tuntap add mode tap user laine group laine name mytap0
ip link set mytap0 up
ip link set mytap0 master br0
(You may want to set a specific MAC address for the tap device, but as
long as it *doesn't* match the MAC address used by the guest emulated
device, it really doesn't matter)
You can now add the following <interface> to a domain definition:
<interface type='ethernet'>
<model type='virtio'/>
<mac address='52:54:00:11:11:11'/>
<target dev='mytap0' managed='no'/>
</interface>
and start up the guest.
A similar set of commands to create a macvtap device named
"mymacvtap0" with MAC addres 52:54:00:11:11:11 connected to the host
device "en2" would be something like this:
ip link add link en2 name mymacvtap0 address 52:54:00:11:11:11 \
type macvtap mode bridge
ip link set mymacvtap0 up
The XML would be identical, except the name of the device
<interface type='ethernet'>
<model type='virtio'/>
<mac address='52:54:00:11:11:11'/>
<target dev='mymacvtap0' managed='no'/>
</interface>
(Note that in the case of macvtap, the precreated device must *match*
the MAC address of the emulated guest device).
If libvirtd is given a precreated device, that device will *not* be
explicitly deleted when qemu is finished with it - the caller must
take care of that.
Laine Stump (9):
util: new function virNetDevMacVLanIsMacvtap()
util: make a couple virNetDevMacVlan*() functions public
qemu: reorganize qemuInterfaceEthernetConnect()
conf: use virXMLFormatElement for interface <target>
conf: new "managed" attribute for target dev of <interface
type='ethernet'>
qemu: support unmanaged target tap dev for <interface type='ethernet'>
qemu: support unmanaged macvtap devices with <interface
type='ethernet'>
qemu: explicitly delete standard tap devices only on platforms that
require it
docs: update news file
docs/formatdomain.html.in | 48 +++++++---
docs/news.xml | 13 +++
docs/schemas/domaincommon.rng | 5 ++
src/conf/domain_conf.c | 55 +++++++++---
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 3 +
src/qemu/qemu_interface.c | 89 ++++++++++++-------
src/qemu/qemu_process.c | 6 +-
src/util/virnetdev.h | 2 +-
src/util/virnetdevmacvlan.c | 35 ++++++--
src/util/virnetdevmacvlan.h | 12 +++
.../net-eth-unmanaged-tap.args | 32 +++++++
.../net-eth-unmanaged-tap.xml | 35 ++++++++
tests/qemuxml2argvmock.c | 16 +++-
tests/qemuxml2argvtest.c | 1 +
.../net-eth-unmanaged-tap.xml | 40 +++++++++
tests/qemuxml2xmltest.c | 1 +
17 files changed, 329 insertions(+), 65 deletions(-)
create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.args
create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.xml
create mode 100644 tests/qemuxml2xmloutdata/net-eth-unmanaged-tap.xml
--
2.21.0