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
_______________________________________________
Users mailing list -- users@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxx
