Greetings Laine,
> Sent: Thursday, August 08, 2024 at 6:16 AM
> From: "Laine Stump"
> To: users@lists.libvirt.org
> Cc: "daggs"
> Subject: Re: cap seach for session libvirt
>
> 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:
> >
>
>
> 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).
>
>
> >
> > > function='0x0'/>
> >
> >
> > 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 , including a bridge='yourbridgename'/>, but *not* including a
> (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
> >
>
>
my goal is rather simple (at least for me), I have a server that runs two vms,
one (denote vm1) is running openwrt, it has 5 nic via pt, the other vm (denote
vm2) runs libreelec.
I need to allow both the host and vm2 access to the lan.
I think I was able to connect vm2 to vm1 using a virtual switch but I still
need to connect the host to vm1.
that is why I'm trying the tap way, I've tried to connect the host using the
virtual switch but didn't got any ip from vm1.
maybe my problem is that I'm not using qemu-bridge-helper, I tried to get it to
work but wasn't able, so I assume I either didn't configured the device
properly in vm1 or didn't configured libvirt to use it properly.
I used this tutorial:
https://mike42.me/blog/2019-08-how-to-use-the-qemu-bridge-helper-on-debian-10.
I'll try again, maybe now it will work
other ideas are welcomed
Dagg
