On 8/7/24 2:25 PM, daggs via Users wrote:
Greetings,
I'm working on allowing a session vm to create a tap iface.
the vm has this defintion:
<interface type='ethernet'>
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).
<mac address='52:54:00:a7:79:6b'/>
<target dev='veth0'/>
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).
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</interface>
when I try to start the vm, I get this error: Unable to create tap device veth0: Operation not permitted
searching the code led me to this line: https://github.com/libvirt/libvirt/blob/0caacf47d7b423db9126660fb0382ed56cd077c1/src/util/virnetdevtap.c#L232
I've looked on line and found out I need the net_admin_cap set. so I took the relevant code in to a dedicated test file and using pam_cap I've defined such cap
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?".
for the test file, all went well.
so I took it back to virsh and defined that cap to virsh but I'm still getting the same issue, see: https://ibb.co/zHggRQZ
the os is debian 12
any ideas why I'm still getting this error?
Thanks,
Dagg
