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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 12, 2024 at 07:31:51PM -0400, Laine Stump wrote:
> 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.

Having actually looked at the code again, the answer is amuzingly/depressingly
obvious.... we already implemented a NULL firewall driver, which is used on
non-Linux, many years ago:

See bridge_driver_platform.c, which does:

  #if defined(__linux__)
  # include "bridge_driver_linux.c"
  #else
  # include "bridge_driver_nop.c"
  #endif

The bridge_driver_nop.c simply does nothing and returns success for
everything. So all the different virtual network modes "work" in
so much as libvirt can start them, but they don't work in the sense
that we're never creating the firewall rules to implement NAT, etc.

So the root cause here is that our "firewall_backend" config logic
completely forgot that the 'nop' driver already existed, and offers
no way to configure it. This is quite simple to address.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux