On 6/12/24 11:46 AM, Andrea Bolognani wrote:
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?
That is very strange, since the default network uses NAT, which requires
firewall functionality (unless they've modified the contents of
default.xml), so I don't see how it could have ever worked.
