On Tue, Feb 20, 2024 at 11:10:22AM -0800, Andrea Bolognani wrote:
On Tue, Feb 20, 2024 at 02:04:11PM -0500, Chuck Lever wrote:
On Tue, Feb 20, 2024 at 10:58:46AM -0800, Andrea Bolognani wrote:
On Tue, Feb 20, 2024 at 10:17:43AM -0500, Chuck Lever wrote:
On Mon, Feb 19, 2024 at 07:18:06PM -0500, Laine Stump wrote:
On 2/19/24 10:21 AM, Chuck Lever wrote:
Hello-
I'm somewhat new to the libvirt world, and I've encountered a problem that needs better troubleshooting skills than I have. I've searched Google/Ecosia and stackoverflow without finding a solution.
I set up libvirt on an x86_64 system without a problem, but on my new aarch64 / Fedora 39 system, virsh doesn't seem to want to start virbr0 when run from my own user account:
cel@boudin:~/kdevops$ virsh net-start default error: Failed to start network default error: error creating bridge interface virbr0: Operation not permitted
If you run virsh as a normal user, it will auto-create an unprivileged ("session mode") libvirt instance, and connect to that rather than the single privileged (ie. run as root) libvirt instance that is managed by systemd. Because this libvirt is running as a normal user with no elevated privileges, it is unable to create a virtual network.
What you probably wanted to do was to connect to the system-wide privileged libvirt, you can do this by either running virsh as root (or with sudo), or by using
# virsh -c qemu:///system
rather than straight "virsh". Whichever method you choose, you'll want to do that for all of your virsh commands, both for creating/managing networks and guests.
These are wrapped up in scripts and ansible playbooks, so I'll have to dig through that to figure out which connection is being used. Strange that this all works on my x86_64 system, but not on aarch64.
This makes me very suspicious. There are a few things that differ between x86_64 and aarch64, but this shouldn't be one of them.
Are you 100% sure that the two environments are identical, modulo the architecture? Honestly, what seems a lot more likely is that either the Ansible playbooks execute some tasks conditionally based on the architecture, or some changes were made to the x86_64 machine outside of the scope of the playbooks.
It's impossible to say that the two environments are identical. The two possibilities you mention are the first things I plan to investigate.
Possible leads:
* contents of ~/.config/libvirt; * libvirt-related variables in the user's environment; * groups the user is part of.
If you have the ability to provision a fresh x86_64 environment to use for a more direct comparison, that would be ideal of course.
At this point I'm not sure the comparison is useful. Something is misconfigured on the aarch64 system. After a fresh boot: cel@boudin:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enP1p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1b:21:e7:ae:56 brd ff:ff:ff:ff:ff:ff inet 192.168.1.64/24 brd 192.168.1.255 scope global noprefixroute enP1p1s0 valid_lft forever preferred_lft forever inet6 fe80::21b:21ff:fee7:ae56/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enP4p3s0u1u3c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 02:21:28:57:47:17 brd ff:ff:ff:ff:ff:ff cel@boudin:~$ virsh -c qemu:///system net-start default error: Failed to start network default error: Requested operation is not valid: network is already active cel@boudin:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enP1p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1b:21:e7:ae:56 brd ff:ff:ff:ff:ff:ff inet 192.168.1.64/24 brd 192.168.1.255 scope global noprefixroute enP1p1s0 valid_lft forever preferred_lft forever inet6 fe80::21b:21ff:fee7:ae56/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enP4p3s0u1u3c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 02:21:28:57:47:17 brd ff:ff:ff:ff:ff:ff 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:7d:89:ef brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever cel@boudin:~$ sudo virsh net-list Name State Autostart Persistent -------------------------------------------- default active yes yes cel@boudin:~$ virsh net-list Name State Autostart Persistent ---------------------------------------- cel@boudin:~$ Starting the default network as "root" throws an error too, though the end result is the bridge is created. The local user still doesn't see a network. -- Chuck Lever