Re: [libvirt PATCH 00/28] native support for nftables in virtual network driver
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