This is a tracking bug for Change: Libvirt Virtual Network NFTables For more details, see: https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables The default firewall backend for the default libvirt virtual network (the virbr0 bridge device), will change from 'iptables' to 'nftables'. If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.
Hi Daniel, could you provide a status update on this change please? Changes need to be code complete before we enter beta freeze next Tuesday 27th August. Are you still on track to land this in F41, or do you need to defer to F42? Thanks, Aoife
This change was actually complete before the Fedora feature was even approved !
I rebased my workstation image on SB41. Everything went quite smoothly, and now my F41 libvirt can even properly shut down my Win11 VM with GPU PCI passthrough properly! Yay! :) ... But unfortunately my VM's NAT interface stopped being able to outbound to the 'net, because I also have `dockerd` installed and running. Maybe I'm in the minority here nowadays? I would have figured a nontrivial number of folks would still be rocking a Docker daemon, though. Point is, I wonder if either a) there should be a more explicit and prominent warning somewhere in the F41 release notes that your VM networking *will* break if you use Docker+libvirt or b) can the machinery be updated to prefer iptables if no explicit preference is set in `/etc/libvirt/network.conf` && `systemctl is-enabled docker.socket`?
hi @me! many sites out in the 'net link back to this issue. i'm also suffering from the issue - and yes, i also have dockerd installed locally. so you described the issue, but sadly didn't document A) why this is a problem (i'm not a nftables/iptables afficionado at all) and B) how can it be workarounded/solved? neither do i want to uninstall docker nor do i understand what implications it has if i set iptables as libvirt networking backend(?) would be greatly appreciated if you or someone else could document that! thanks ps: yes, it is so vital to me that i created this account solely for being able to post this comment here ;-)
I can't give a complete answer for A) since I'm not 100% clear on the specifics myself. My (likely incorrect) layman's understanding is that nftables is kinda of like what IPv6 is to IPv4: a fundamental rewrite/reimagining of the packet filtering/switching layer in the kernel. It's not compatible with iptables at all, so instead iptables will get first dibs on a packet, and if it doesn't do anything with it, nftables is given a chance. The issue in this specific case is that if you're using dockerd, it's registering some iptables rules that interfere with packets on the private network, and those packets are then never seen by nftables. Thus, if you let libvirt operate in its now default (since F41) mode of using nftables, packets destined for libvirt VMs are being blackholed by the dockerd iptables rules. And so that brings us to B), how to solve this. You simply ensure the line `firewall_backend = "iptables"` is present in your `/etc/libvirt/network.conf` (and then `sudo systemctl restart virtnetworkd`). This will ensure libvirt registers its essential networking rules in iptables instead of nftables, ensuring that the necessary rules get a chance to do their thing before dockerd's do.
Please don't report issues you're having on this *closed* bug. This bug is just a tracker for the feature implementation . If anyone has ongoing problems, please file *new* bugs for each problem encountered so that can be investigated & triaged as needed. If you think this feature change was the cause, it is sufficient to just mention that in the newly filed bug description.
(In reply to Daniel Berrangé from comment #6) > Please don't report issues you're having on this *closed* bug. This bug is > just a tracker for the feature implementation . If anyone has ongoing > problems, please file *new* bugs for each problem encountered so that can be > investigated & triaged as needed. If you think this feature change was the > cause, it is sufficient to just mention that in the newly filed bug > description. FWIW, unless this was a canned reply, I think it was kinda pointless to bang out this Internet Policing Service Announcement, rather than just open such a follow-up bug yourself. I mean, you're a RH employee and the one who introduced this situation, right? Isn't Red Hat paying you enough to do a warranty period or something? ;) (Especially since there's now two independent confirmations of this issue) I personally didn't care enough about the broken behaviour to pursue it any further than the drive-by comment back in October. I still stand by that, since it clearly helped at least one other person out there! Anyway, since we're all offering unsolicited advice to strangers on the internet, here's mine: it would have been more useful to open that follow-up bug yourself, and *then* admonish randoms as to how to do things "properly".