[libvirt] [PATCH 0/9] support use of precreated tap devices from unprivileged libvirtd

Laine Stump laine at laine.org
Thu Sep 5 16:00:49 UTC 2019


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
>




More information about the libvir-list mailing list