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>

> 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'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.

> 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. Looks like you don't have the if_bridge kernel module loaded. If you run 'virt-host-validate', it should show if something's missing.

Andrea Bolognani wrote: > On Thu, Jun 13, 2024 at 07:45:52PM GMT, Roman Bogorodskiy wrote: > > Looks like you don't have the if_bridge kernel module loaded. > > > > If you run 'virt-host-validate', it should show if something's missing. > > Yeah, that was it. Probably worth adding a hint to the message > displayed upon package installation? It's already referring to https://libvirt.org/drvbhyve.html which mentions that additional kernel modules should be loaded, so I think that should be good enough.

Laine Stump wrote: > On 6/12/24 2:32 PM, Roman Bogorodskiy wrote: > > 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). Yes, I've changed it to mode='open' and it still works for me, i.e. I have host<->guest connectivity. So it would make more sense to change the default to 'open', at least until nat is not supported. I think I'd better do that on the packaging level.

Andrea Bolognani wrote: > Honestly I'm not entirely sure it makes much sense to have the > network driver and especially the default network if you need to > bring your own firewall rules, but that can be a separate discussion. Hm, I think the network driver is quite usable without QEMU, e.g. I use it with bhyve.

I also find it quite useful even without firewall rules. Most of the time internal connectivity is enough for my guests. Configuring NAT on per-network basis is also fairly easy. For more advanced scenarios hooks could be used, though I haven't done that specifically.

On 6/12/24 2:32 PM, Roman Bogorodskiy wrote: > Laine Stump wrote: > > > On 6/10/24 2:54 PM, Roman Bogorodskiy wrote: > > > Laine Stump wrote: > > > > > > > This patch series enables libvirt to use nftables rules rather than > > > > iptables *when setting up virtual networks* (it does *not* add > > > > nftables support to the nwfilter driver). It accomplishes this by > > > > abstracting several iptables functions (from viriptables.[ch] called > > > > by the virtual network driver into a rudimentary "virNetfilter API" > > > > (in virnetfilter.[ch], having the virtual network driver call the > > > > virNetFilter API rather than calling the existing iptables functions > > > > directly, and then finally adding an equivalent virNftables backend > > > > that can be used instead of iptables (selected manually via a > > > > network.conf setting, or automatically if iptables isn't found on the > > > > host). > > > > > > Hi, > > > > > > Apparently, I'm late to the discussion. > > > > > > I noticed that now I cannot use the bridge driver on FreeBSD as it's > > > failing to initialize both iptables and nftables backends (which is > > > expect). > > > > Yeah, previously we wouldn't check if iptables was available until someone > > tried to start a network that would need to use it, and would then log an > > error (and just fail starting that network, but the network driver would > > remain running). But now we figure out which firewall backend to use > > immediately when the driver is loaded, and if we fail to fin a workable > > backend we fail the entire driver init.r > > > > How did you use the network driver before? With a <forward mode='open'/> > > network? Truthfully I hadn't ever considered the case of someone using it > > with only network types that didn't need firewall rules. I wonder if there > > are other platforms we support that have a usable network driver for > > <forward mode='open'/> (MacOS?) > > 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> > > 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). > > Unfortunately, I don't have access to that setup anymore and I haven't > re-created it yet. IIRC, it could probably show some warnings about > missing iptables, but it didn't affect anything for me. I'm surprised that there wasn't a fatal error while starting the network though.