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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
