On Mon, Feb 26, 2024 at 03:12:51PM -0500, 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.
I found the answer; posting here for the archive.
There was a bug in the Ansible playbook responsible for setting up
libvirt to "run as a regular user". It was enabling libvirtd, but
was failing to enable virtnetworkd. On Fedora systems, both of
these steps are necessary.
Once that was corrected, virtual networking works without error.
Glad to hear you managed to figure it out. As suspected, it wasn't an
aarch64-related issue after all :)
Note that you shouldn't enable both the monolithic daemon (libvirtd)
and the modular daemons (virtnetworkd, virtqemud) at the same time.
If your version of libvirt is recent enough (>= 9.9.0) the situation
should be handled cleanly, but in general it's not a supported
configuration.
Moreover, Fedora has defaulted to modular daemons for a long time
now, so really you shouldn't need to do anything special to ensure
that they are enabled. Just install the package, then either start
the various services/sockets manually or simply reboot. That should
do the trick.
--
Andrea Bolognani / Red Hat / Virtualization