On Wed, Jun 12, 2024 at 01:54:47AM -0700, Andrea Bolognani wrote:
On Tue, Jun 11, 2024 at 05:27:42PM GMT, Daniel P. Berrangé wrote:
> On Tue, Jun 11, 2024 at 08:49:42AM -0700, Andrea Bolognani wrote:
> > One additional issue with this:
> >
> > $ PATH=/usr/bin /usr/sbin/libvirtd
> > error : virNetworkLoadDriverConfig:146 : internal error: could not
> > find a usable firewall backend
> > error : virStateInitialize:672 : Initialization of bridge state
> > driver failed: internal error: could not find a usable firewall
> > backend
> > error : daemonRunStateInit:617 : Driver state initialization failed
> >
> > This happens because nft and iptables are both in /usr/sbin, so if
> > the user's $PATH doesn't include that directory they won't be
found
> > and the driver will fail to initialize.
> >
> > Not a big deal on Fedora, where /usr/sbin is part of the default
> > $PATH for users, but that's not the case on Debian, where
> > qemu:///session is just completely broken right now.
> >
> > I was testing out a patch that addressed the situation by switching
> > backend detection to virFindFileInPathFull(), but then I realized
> > that it's fairly pointless to look for nft/iptables when a regular
> > user can't run them anyway.
> >
> > So what I think we need to do is, make the failure to detect a
> > working backend non-fatal, unless the user has explicitly asked for a
> > specific backend to be used. That should bring us back to the
> > previous situation.
>
> This is probably another reason to have a "no op" backend that merely
> raises errors for every operation - see my Roman's mail about FreeBSD
Is there much of a difference between having an explicit noop backend
that is checked for availability after all other ones, and simply not
failing to initialize the driver if a backend can't be found?
I actually sent a patch for the latter last night
Anyway, I'd be happy with either solution.
I'm still unclear on how networking on FreeBSD could work at all
until now. Aren't the iptables rules needed for guest connectivity?
Or did I misunderstand their purpose?
It wouldn't have worked, but the problem is that we now kill the
entire libvirtd startup, instead of successfully starting a (broken)
network driver. Both are broken, but now the brokenness has spread
to the bits that do matter.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|