Re: non-root bridge set-up on Fedora 39 aarch64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Feb 27, 2024 at 09:49:23AM -0500, Chuck Lever wrote:
> On Tue, Feb 27, 2024 at 01:20:46AM -0800, Andrea Bolognani wrote:
> > 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.
> This Ansible code dates from before 2020, so it's legacy, I suppose.

The change in default from monolithic daemon to modular daemons feels
like forever ago to me, but in reality it only happened[1] with
Fedora 35 in late 2021. So it's understandable that there would be
code out there that is not prepared to cope with this scenario.

> Perhaps, if it can figure out which version of libvirt is available,
> Ansible needn't start libvirtd at all? It would be a nicer fix, that
> I can subsequently contribute to kdevops, if Ansible would start a
> supported libvirt configuration.

Looking at the Fedora-specific part of enabling libvirt in
kdevops[2], I'm pretty sure that what it attempts to do is not right.

Specifically, it starts libvirtd, then starts virtnetworkd. As I
mentioned earlier, mixing the monolithic daemon with the modular ones
is very much an unsupported configuration. Fedora 39 has libvirt
9.7.0, which doesn't contain the systemd cleanups I talked about
above, so the consequences of doing this are likely going to be even
more nasty.

I don't understand why starting virtnetworkd would be needed in the
first place. The only difference between a monolithic deployment and
a modular one should be in which process each of the drivers is
running. If a running virtnetworkd allows you to do what you need,
networking wise, so should running libvirtd.

I will admit that I have never tried the "split" setup that you seem
to be aiming for, e.g. libvirtd/virtqemud running as an unprivileged
user but getting access to the host's networking via a privileged
virtnetworkd instance or other setuid trickery.

Looking at the libvirt-specific configuration knobs in kdevops[2],
it seems that qemu:///session is used by default on Fedora, and on
Fedora only. That honestly feels like a questionable choice to me...
Everywhere else, qemu:///system is used instead, so I'm not surprised
that issues would show up when you're exercising the odd path out.

> > 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.
> I too expected that simply installing libvirt on my new Fedora 39
> system would have created a working environment, so there's clearly
> something I missed during set-up.

One thing that people often miss, because it's admittedly not so
obvious, is that it's not enough to install the libvirt package to
start using libvirt: you also need to start the corresponding
services, or at least their sockets.

This is not something that's specific to libvirt, but rather the
consequence of a more general policy adopted by RHEL-derived distros,
where services are not automatically started after installation.
Debian-derived distros have the opposite policy, so you get a
smoother out of the box experience there.

Unfortunately, this being a distro-wide policy, there's not much we
can do about it.

Andrea Bolognani / Red Hat / Virtualization
Users mailing list -- users@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxx

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux