On Wed, Jun 12, 2024 at 07:31:51PM GMT, Laine Stump wrote:
On 6/12/24 2:32 PM, Roman Bogorodskiy wrote:
I'm using it with the following network configuration:
virsh # net-dumpxml default <network> <name>default</name> <uuid>2a1415c9-325b-41e4-82c6-e805162d8934</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:24:fa:43'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network>
My configuration is the same (obtained from copying the file shipped as /usr/local/share/examples/libvirt/networks/default.xml, which is identical to src/network/default.xml.in in the libvirt tree) and I get an error when I try to start the network: # virsh net-start default error: Failed to start network default error: Unable to create bridge device: Invalid argument The debug log reveals the source of the error to be virNetDevBridgeCreate:474 I don't understand how that would work for you. My setup is completely vanilla, just a plain FreeBSD 14.1 install. The only thing that could possibly be making any difference is that the host's network interface is a wireless one.
So basically all the mechanics like creating tap devices, bridges, serving dhcp, etc, all these work for me. On top of that I had a few iterations of manual firewall configurations (with both ipfw and pf) to implement NAT on guests.
Okay, so essentially it was effectively <forward mode='open'/> (since the only difference is the lack of libvirt-added firewall rules).
[...]
I think even with a NULL firewall backend it still should log an error and fail if someone tries to start a network that requires firewall rules though (i.e. your above config would still fail, unless it's changed to <forward mode='open'/>)
I agree. The fact that this was allowed in the first place is arguably a bug
I'm about to be offline for 3 weeks, but in the meantime if you'd like to try making a NULL backend that is only an option if it's listed in firewall_backend_priority (you'll need to remove the compile-time check that all possible backends are accounted for - I think that is the first of the two G_STATIC_ASSERTS at the top of virNetworkLoadDriverConfig()), always initializes successfully in bridge_driver_conf.c if it is listed in the options, and then in networkAddFirewallRules add a check to log an error and fail if backend == NULL (something about attempting to start a network type that would require firewall rules, but the system not having any of the supported types of firewallbackend or something - it's too late now and my brain is too fried and sleepy to think of good wording :-)). As long as it isn't a valid selection on Linux builds that are done with firewall_backend_priority=nftables,iptables, but *is* a valid selection if the setting is "firewall_backend_priority=null" that shouldn't be *too* controversial.
I think we can treat the null backend just like the other ones. New default: -Dfirewall_backend_priority=nftables,iptables,null Works fine on Linux (even for qemu:///session) and FreeBSD. If you don't want firewall rules to ever be created (rules out mode=nat) for whatever reason: firewall_backend = "null" Same as above, but at compile time: -Dfirewall_backend_priority=null,nftables,iptables If you changed your mind later but don't want to recompile, or disagree with the package maintainer: firewall_backend = "iptables" Seems pretty reasonable and seamless to me. -- Andrea Bolognani / Red Hat / Virtualization