+++ This bug was initially created as a clone of Bug #1723367 +++

Currently, libvirt takes upon itself to create a macvtap device on top of a host interface. I'd like libvirt to be able to do less.

I'd like to create a macvtap device and configure it to my liking (in a CNI), and make it available to libvirt which runs as a normal user in its own netns.

I would like to specify the device it as a <source dev='macvtap0'> element, and have libvirt connect it to qemu.

--- Additional comment from Laine Stump on 2019-08-08 05:59:59 CEST ---

Today I was finally able to put together a proper test for this, and successfully started a guest with session-mode (unprivileged/non-root) libvirtd that used a pre-created macvtap device. My test was this:

(as root)
# ip link add link p14p1 name mymacvtap0 address 52:54:00:12:12:12 type macvtap mode bridge
# ip link set dev mymacvtap0 up
# chown laine:laine /dev/tap$(ip link show mymacvtap0 | head -1 | cut -d: -f1)

(as user laine)

# virsh define [a guest with the following interface definition]

   <interface type='direct'>
      <mac address='52:54:00:12:12:12'/>
      <source dev='p14p1' mode='bridge'/>
      <target dev='mymacvtap0'/>
   </interface>

# virsh start [that guest]

If the macvtap device didn't exist, or the mac address of the macvtap device is different from what's in the definition, it would log an error. Conversely, the setting of source dev and mode are ignored - that's only used during device creation, and my patch bypasses device creation completely when the device already exists.

This could maybe be made a bit friendlier in the error reporting department (e.g., right now it will complain that it can't create a non-existing device rather than saying that it can't create it due to insufficient privileges), but it would be at least good enough to try it out and see if this is what you want to do.

I'll send a patch upstream tomorrow AM (US EST), and try to make either a RHEL8 or Fedora 30 rpm for you if it would be useful.

(It's a very minor patch once I got enough time to actually think through it).

--- Additional comment from Laine Stump on 2019-08-19 06:27:35 CEST ---

I thought about this more before sending a patch, and realized I didn't want the simple patch because it is a hack.

In the meantime I've also found that a small modification to the device setup for conventional tap devices makes precreated standard taps usable from a non-privileged libvirt too - as with macvtap devices, it the tap device is created as owned by the uid of the process running libvirtd, and as long as we avoid attempting to set the MAC address or modify the interface flags (e.g. to set IFF_UP or MULTIQUEUE) then it can be opened by the unprivileged libvirtd and consumed successfully by qemu.

I'm now thinking that this could all be exposed to libvirt's consumers with an extra option to <interface type='ethernet'>, e.g.:


     <interface type='ethernet'>
       <target dev='tapdevname' unmanaged='yes'/>
       ...
     </interface>

Any network device declared like this would be opened, but no setup would be done (no mac address setting, no interface flags, no MTU).
This could work for both macvtap and standard tap even though they each use a different method of opening the fd for the device - just check first whether or not it's a macvtap device. )There could be disagreement with this, since in the past type='ethernet' was used only for standard tap devices.)

--- Additional comment from Laine Stump on 2019-08-28 03:50:18 CEST ---

I just posted patches upstream that support use of precreated tap and macvtap devices by an unprivileged libvirt.

 https://www.redhat.com/archives/libvir-list/2019-August/msg01256.html

(I did switch the attribute name to "managed" :-)

I don't know that this can be reviewed in time for the feature freeze for 5.7.0, since that will be happening within 12-16 hours.