Re: [libvirt PATCH 00/28] native support for nftables in virtual network driver

On Wed, Jun 12, 2024 at 10:42:43AM GMT, Laine Stump wrote: > On 6/12/24 9:18 AM, Andrea Bolognani wrote: >> On Wed, Jun 12, 2024 at 08:42:48AM GMT, Laine Stump wrote: >>> On 6/12/24 6:47 AM, Daniel P. Berrangé wrote: >>>> On Wed, Jun 12, 2024 at 03:27:24AM -0700, Andrea Bolognani wrote: >>>>> [...] I'd be extremely surprised to learn that >>>>> guest network connectivity hasn't worked on FreeBSD all this time. >>>>> Surely that can't be right! Roman, what am I missing? >>>> >>>> This is only the libvirt virtual network backend. I presume BSD hosted >>>> guests could just use one of the other network backend options. >>> >>> Based on the wording of Roman's initial message, I wondered if possibly >>> people had been using the virtual network driver with <forward mode='open'/> >>> - this wouldn't ever call any firewall functions, so it should succeed. >> >> It looks like it fails before it can even get to the point where >> firewall rules would be created: >> >> # virsh net-start default >> error: Failed to start network default >> error: Unable to create bridge device: Invalid argument > > Okay, then I guess I read too much into what Roman said: > > I noticed that now I cannot use the bridge driver > on FreeBSD as it's failing to initialize both > iptables and nftables backends > > I figured that meant the bridge driver (aka the network driver) had > previously been usable on FreeBSD, but if your test is typical, then that's > not the case; maybe only <interface type='bridge'> works, and Roman just > assumed that the network driver was needed in order for that to function. This is a bog-standard FreeBSD installation, so whatever I'm seeing is the out-of-the-box experience. Maybe there's a way to get things working with further tweaking, I don't know. > If a platform supports standard tap devices (which FreeBSD does), the three > things the network driver needs to function properly are 1) a functioning > firewall backend, 2) dnsmasq, and 3) the ability to manage a bridge device > (all the functions in virnetdevbridge.c). (1) is obviously missing, but (2) > is present on FreeBSD, and it looks like, at least for some *BSDs, (3) is > also available (there is a build-time flag WITH_BSD_BRIDGE_MGMT that is set > if certain ioctls are defined in net/if_bridgevar.h). > > Is WITH_BSD_BRIDGE_MGMT set in your FreeBSD build? Yes. > Does net/if_bridgevar.h exist? Also yes. >> I'm not even sure why the network driver is enabled on FreeBSD in the >> first place. Only the QEMU driver can use it, right? And that's >> compiled out by default on FreeBSD, if I'm interpreting the port[1] >> correctly. So, at the very least, I would expect the network driver >> to only be enabled when the QEMU driver is, i.e. not in the default >> binary package. More on this. When installing libvirt, the following message is printed out: NOTE ON CONFIGURATION: The libvirt port does not come with networking configuration enabled. The 'default' network definition is available at: /usr/local/share/examples/libvirt/networks/default.xml To enable this network please do the following: cp /usr/local/share/examples/libvirt/networks/default.xml /usr/local/etc/libvirt/qemu/networks To configure this network for autostart, execute the following: ln -s ../default.xml /usr/local/etc/libvirt/qemu/networks/autostart/default.xml If you have libvirtd already running you'll need to restart it for changes to take effect. As seen earlier, these instructions are pointless, as the default network won't be able to start. But the fact that they exist at all seems to indicate that, at some point, the default network could work on FreeBSD?