ping.
Aside from review, I'm interested whether or not there is agreement with
using type='ethernet' for precreated *macvtap* devices as well as
standard tap - on one hand macvtap devices have traditionally been
handled by type='direct'; on the other hand, type='direct' requires/uses
info about how the device is connected to the network, which we don't
have / can't use when the device is pre-created by someone else, and
type='ethernet is specifically for network devices that have their
connection setup "elsewhere" outside of libvirt (it's really just a
quirk of their implementations that the method for getting a handle to a
standard tap device is by opening /dev/tun/tap and calling
ioctl(TUNSETIFF), while the way to get a handle for a macvtap device is
to open /dev/tap${ifindex} - they're otherwise essentially the same
thing from the POV of qemu, just an fd that's used as a gazinta/gazouta
for packets).
On 8/27/19 9:46 PM, Laine Stump wrote:
> 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
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list