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_user/tasks/install-deps/fedora/main.yml [3] https://github.com/mcgrof/kdevops/blob/master/kconfigs/Kconfig.libvirt -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Users mailing list -- users@xxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxx
