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