On Tue, Feb 27, 2024 at 08:09:17AM -0800, Andrea Bolognani wrote: > 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. I confess I don't understand the libvirt_user role well enough to effect any changes here except to add an action to enable virtnetworkd. > > > 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. That must be it: enabling libvirtd.service appears to add in the socket services too: root@boudin:~# systemctl enable libvirtd Created symlink /etc/systemd/system/multi-user.target.wants/libvirtd.service → /usr/lib/systemd/system/libvirtd.service. Created symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket → /usr/lib/systemd/system/virtlockd.socket. Created symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket → /usr/lib/systemd/system/virtlogd.socket. Created symlink /etc/systemd/system/sockets.target.wants/libvirtd.socket → /usr/lib/systemd/system/libvirtd.socket. Created symlink /etc/systemd/system/sockets.target.wants/libvirtd-ro.socket → /usr/lib/systemd/system/libvirtd-ro.socket. root@boudin:~# -- Chuck Lever _______________________________________________ Users mailing list -- users@xxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxx
