From the BUG-Report: https://gitlab.com/libvirt/libvirt/-/issues/645

Laine Stump
@lainestump · vor 19 Stunden
Developer

The behavior as you've described is correct. Having iptables-legacy installed does not mean that you don't have nftables installed, it just means that:

when an iptables command is issued, communication between the iptables application and the kernel is accomplished via the iptables API rather than the nftables API, and

when you run "nft list ruleset" you will not see the rules that were added with iptabls commands; you will only see those rules when you run iptables -S/-I (when iptables-nft is in use, you see the iptables rules in both places)

The difference between iptables-nft and iptables-legacy is all explained here:

https://developers.redhat.com/blog/2020 … -nftables#

When libvirt checks for the availability of nftables, it is just checking if the "nft" user command is available somewhere in $PATH. So if the auto-config is set to prefer nftables and you want libvirt to use iptables, you must either set it in /etc/libvirt/network.conf, or you must uninstall the userland package that provides /usr/sbin/nftables, which in the case of Fedora is the package "nftables" (and I would assume it's the same on Arch). Removing that package wont remove nftables functionality from the kernel (which is good, because anyway iptables uses that!), but it does get rid of /usr/sbin/nft, and once that is done, libvirt will correctly determine that the nftables backend is non-viable, and will select the iptables backend instead.

Because the reported bahavior is correct, I'm closing this issue.