On 8/8/24 2:40 AM, daggs wrote:
Greetings Laine,
Sent: Thursday, August 08, 2024 at 6:16 AM
From: "Laine Stump" <lstump@xxxxxxxxxx>
To: users@xxxxxxxxxxxxxxxxx
Cc: "daggs" <daggs@xxxxxxx>
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:
<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
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,
What is "pt"? Do you mean VFIO device assignment (i.e. "passthrough"?)
the other vm (denote vm2) runs libreelec.
I need to allow both the host and vm2 access to the lan.
When you say "access the lan", do you mean that they need to be on the
same subnet as the physical lan? And are you implying here that the
openwrt VM should *not* be directly on the lan?
I think I was able to connect vm2 to vm1 using a virtual switch
What do you mean by "virtual switch"? A Linux host bridge? What is the
configuration of that bridge? Is it attached to a host physical
ethernet? what is the <interface> config of the two VMs? (AIn short -
"You haven't given me any details, and so I don't know what I'm working
with, and that makes it nearly impossible to tell you what to do next." :-))
but I still need to connect the host to vm1.
If you are connecting vm2 to vm1 using a Linux host bridge, then all you
need to do is give that host bridge an IP address - then both vm1 and
vm2 can communicate with the host via that IP address.
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.
What did you do to "try connecting the host using the virtual switch"?
Instead of a generalized summary, give me the exact changes you made to
libvirt and host system config.
Also, this statement implies that you have a dhcp server running on vm1,
and that you want the host to get its IP from vm1's dhcp server. Is that
correct? If so, how were you planning to enable dhclient for the host
side of the tap device after creating it at runtime? This just doesn't
seem practically achievable.
maybe my problem is that I'm not using qemu-bridge-helper, I tried to get it to work but wasn't able,
... which implies that the connection you made between vm1 & vm2 was not
via a Linux host bridge, since qemu-bridge-helper is the only method of
connection a session mode libvirt guest to a Linux host bridge, so now
I'm just confused :-P.
What exactly was the <interface> config of the guest, and what what the
symptom(s) of "not working"? What was in the <interface> section of "virsh
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 took a look there and that really is all there is to it - one
difference I see from the situation on Fedora is that the
qemu-bridge-helper is apparently in /usr/lib/qemu on debian, rather than
in /usr/libexec as it is on Fedora. Is that correct?
If you follow those instructions exactly, then your VMs should have IP
addresses on 192.168.112.0/24, as will the host (it will be visible to
the VMs at 192.168.122.1) - exactly the same as if you were using
qemu:///system and <interface type='network'><source network='default'/>.
I'll try again, maybe now it will work
other ideas are welcomed
It would really help to see a drawing (either ASCII drawing directly in
email, or a link to an image of a drawing (either computer-generated or
hand-drawn) on imgur or some similar site (please don't send graphic
attachments to the mailing list :-)). This drawing should show 5
entities (host, vm1, vm2, physical lan, internet connection) with lines
showing which interfaces of which machines should be on the same subnet.
Having that would greatly help in being able to give you productive advice.
