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.
--
Andrea Bolognani / Red Hat / Virtualization