Re: [libvirt PATCH 00/28] native support for nftables in virtual network driver

On Tue, Jun 11, 2024 at 02:38:58AM GMT, Andrea Bolognani wrote: > On Mon, Jun 10, 2024 at 09:10:08PM GMT, Roman Bogorodskiy wrote: > > Laine Stump wrote: > > > > > This patch series enables libvirt to use nftables rules rather than > > > iptables *when setting up virtual networks* (it does *not* add > > > nftables support to the nwfilter driver). It accomplishes this by > > > abstracting several iptables functions (from viriptables.[ch] called > > > by the virtual network driver into a rudimentary "virNetfilter API" > > > (in virnetfilter.[ch], having the virtual network driver call the > > > virNetFilter API rather than calling the existing iptables functions > > > directly, and then finally adding an equivalent virNftables backend > > > that can be used instead of iptables (selected manually via a > > > network.conf setting, or automatically if iptables isn't found on the > > > host). > > > > [resend to a proper list] > > > > Hi, > > > > Apparently, I'm late to the discussion. > > > > I noticed that now I cannot use the bridge driver on FreeBSD as it's > > failing to initialize both iptables and nftables backends (which is > > expect). > > > > What would be a good way to address that? I see at least two options: > > > > 1. Add a Noop firewall driver > > 2. Implement a "real" FreeBSD driver based either on pf or ipfw (that's > > been on my TODO list forever, but I somehow got stuck on the very first > > step on choosing between pf and ipfw). This obviously will take much > > more time. > > > > Maybe there are other options I'm missing. > > > > What do you think? > > If I understand correctly, the new behavior might cause problems on > macOS too, see [1]. I wouldn't be surprised if the other BSDs were > similarly affected. > > I wonder how things could work before if the iptables backend is not > functional. Is it possible that we used to ignore failures to > initialize the backend, but now we consider them fatal instead? > > A proper platform-specific backend would obviously be the right > approach in the long run, but the priority should be restoring the > previous status quo. A noop backend might be the answer, but honestly > I just don't understand enough about networking to know for sure. I > thought that these firewall rules were necessary in order to give > network access to VMs, but if FreeBSD has been doing fine without > iptables so far clearly that's not the case? 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.