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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux