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 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

> > > 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/ → /usr/lib/systemd/system/libvirtd.service.
Created symlink /etc/systemd/system/ → /usr/lib/systemd/system/virtlockd.socket.
Created symlink /etc/systemd/system/ → /usr/lib/systemd/system/virtlogd.socket.
Created symlink /etc/systemd/system/ → /usr/lib/systemd/system/libvirtd.socket.
Created symlink /etc/systemd/system/ → /usr/lib/systemd/system/libvirtd-ro.socket.

Chuck Lever
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