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? 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? -- Andrea Bolognani / Red Hat / Virtualization
