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
