Re: cap seach for session libvirt

On 8/7/24 2:25 PM, daggs via Users wrote: If you were able to create a tap device with session-mode libvirt, what would you do with it? It's not connected to anything, and your session-mode libvirt wouldn't be able to set an IP address (which would permit traffic to be *routed* to it by the host ip networking). Is there a particular reason you're wanting to name the device "veth0"? That naming is usually use for veth devices (these are two-sided network devices that are created in pairs, both looking like an ethernet. They can be used to connect an LXC container running in a separate network name space to the host's network name space (they are, as a matter of fact, what libvirt's LXC driver uses to implement networking in LXC containers). They are of really no use to a QEMU VM though. I'm pointing this out because it's possible that the Linux kernel makes some assumptions based on a device's name (unlikely, but also humans might make incorrect assumptions based on the name). The whole point of session mode libvirt is that it *can't* get all those extra caps which would permit it (or the guest it runs) to wreak havoc on the host by (for example) creating a tap device connected to some random place. The way to get tap devices created for guests running under session mode libvirt is to make sure the qemu-bridge-helper is installed/setup properly on the host (including adding a line for the bridge device you want to connect to into /etc/qemu/bridge.conf), then just use <interface type='bridge'>, including a <source bridge='yourbridgename'/>, but *not* including a <target dev='blah'/> (since qemu-bridge-helper will determine the name for the tap device it creates). At guest start time. libvirt will see that a tap device is needed, then exec qemu-bridge-helper (which is a suid-root binary with the necessary caps to create a tap and connect it to a bridge) to create the tap device and connect it to the specified bridge. It passes the name of the tap device back to libvirt, which in turn provides the tap device to QEMU. Of course your example suggests that you don't want the tap device connected to a bridge, but in that case again I would ask "Why?".