10:09 a.m.
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.
[1] https://pagure.io/fesco/issue/2627
[2]
https://github.com/mcgrof/kdevops/blob/master/playbooks/roles/libvirt_use...
[3] https://github.com/mcgrof/kdevops/blob/master/kconfigs/Kconfig.libvirt
--
Andrea Bolognani / Red Hat / Virtualization