On Fri, Feb 21, 2025 at 04:02:25PM -0800, robinleepowell(a)gmail.com wrote: That's an interesting idea and worth a try. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Mon, Feb 24, 2025 at 04:25:58PM -0500, Laine Stump wrote: Yep! Sorry, thought I linked to it, oops. https://lore.kernel.org/netfilter/132daf73-668f-4321-8945-c809db2277f5@re... Yep, those are all real concerns. :sigh: I think it'd have to be the latter to actually work. The reason I have to use iifname is that at the time my rules are loaded, the virbr interfaces *don't exist*. Like I actually have no choice; it won't work the other way, unless I'm badly missing something. No attack intended; FOSS work is hard. :) That's fair; I suppose we could post something equivalent to the old iptables rules? Acknowledged. :)

On 2/25/25 1:58 AM, Robin Lee Powell wrote: Thanks! (I'm surprised I've never subscribed to that list, so that it could be yet another folder with ever-increasing number of unread messages :-/. Seriously though, I probably should be paying attention to it) My one comment about their response/advice is that, while they suggest that libvirt shouldn't be adding any firewall rules but should instead just have docs telling people what rules they need to add, the entire purpose of libvirt's virtual networks was to provide essentially a single "That was Easy" button that can be pushed which sets up *everything* needed for a guest to communicate with the outside - the user can just say "create a network using NAT forwarding" and libvirt creates the bridge device, sets up the DHCP and DNS servers listening on that bridge device, turns on IP forwarding (if it's off) and also adds all the rules necessary to allow the traffic to pass (and to NAT the packets if that was requested). If we did "all those things *except* the firewall rules" it would add another hurdle for inexperienced users to get their VMs fully functional. (BTW, if someone wants that, they can just define the network with <forward mode='open'/> and it will setup everything except the firewall rules). In my opinion, libvirt definitely *should* be adding the appropriate rules (for the types of networks that are meant to be the most "plug and play"), but also (and this is where the netfilter people are correct) should do a better job of documenting what might need to be done beyond that on some systems. In the meantime we should do our best to automate (or at least specifically document) the "what might need to be done" for as many other utilities as possible (for example the way we put all our bridge devices in a special firewalld zone that we automatically add to firewalld's configuration). Yeah, good point. One alternate method you could experiment with if you thought that the string compare was having anything more than a .0005% effect on performance would be to use a libvirt network hook script (https://libvirt.org/hooks.html ) - if you put your rule additions in /etc/libvirt/hooks/network in the section run when argv[2] is "started" then the bridge device (which you could grab out of the XML provided to the script on stdin) would already be created. The down side is that once you've added a hook script, all your networks are marked as "tainted" which could create supportability problems if you were paying someone for support; since you're using Fedora that's not a problem though :-) (I do recall someone at one point posting a perf chart where it showed a significant amount of the kernel time on their system was spent doing strcmp of the interface names. I don't remember exactly how much or where it was posted, but I do remember being surprised at how much CPU was used up for that...) (I'm pretty sure there is a missing partial sentence in between the "I I" up there, but no idea what that partial sentence was, which is an example of the attention span that has led to (for example) this lack of proper documentation :-P) None perceived :-). Over the years there have been (fortunately not too many, but certainly more than enough!) irate and hostile messages that have gone by on this and other lists, but yours have not been in that class - to the contrary, you're providing the necessary information for us to understand your problem, doing your own investigation to help narrow it down and better define it, and even volunteering to do some of the work to fix it - that's the definition of being a good FOSS community citizen :-) (oh, and I forgot the part about not indiscriminately hurling insults around :-P) Yeah, and say something like "for minimal functionality and connection to the outside" And I do also like the idea of marking all the traffic that libvirt's rules accept (and adding back the rules / marking the packets for the basic functionality that our network setup provides). While it may not work for everyone, it would likely be easier for someone to use the info "accept all traffic with mark xyzzy" than to give out a list of all the things that need to be accepted (and also more efficient, since there would then be only a single extra rule in the other table no matter how many libvirt networks were active). I'll add this to my list of things to do and try to get to it this week while it's fresh in my mind; I'll be sure to Cc you on the patches so you'll know when there is something available to experiment with.

On Tue, Feb 25, 2025 at 02:26:44PM +0000, Daniel P. Berrangé wrote: I had exactly the same response as both of you. :) Which is why I didn't bother replying to that part.