[libvirt] [RFC] Switch to nftables from netfilter

[Daniel P. Berrange]

On Tue, Jul 26, 2016 at 04:25:17PM +0200, Michal Privoznik wrote:
> Dear list,
> 
> I've came across nftables [1]. They look very promising, more than old
> netfilter. It offers new features [2], from which I'd pick:
> 
> - better performance under high traffic workloads
> - atomic filter/chain replacements
> - transactions
> 
> I haven't investigated how much work will be required on our side if we
> try to implement the switch (well, for starters, we can have two
> subsystems living next to each other). I want to check what do you guys
> think before actually digging into the code.
> 
> The nftables was merged into 3.13 Linux kernel and thus should be
> available on all major distros. Well, since we will have both subsystems
> available, we should be good to go.

So from the kernel side netfilter & nftables are completely separate
subsystems, but you don't really want to use both at the same time on
the same host.  In theory there's compat code to translate [eb,ip,ip6]tables
commands to nft commands, but IIUC that is incomplete.

IOW, there is likely to need to be a "flag day" for each distro when they
switch over to use nftables, and all apps dealing with firewalls will need
to be capable of switching at once.

So a nftables backend is not immediately useful for libvirt, but at the
same time, developing one is probably a pre-requisite for any distro using
libvirt to be able to switch to nftables.

Firewalld does not currently have any nftables support in its git master
either. If it does, then there's an open question as to whether libvirt
should actually continue to use firewalld or not.  We use firewalld today
because netfilter has a fixed set of base chains, and we need to preserve
libvirt rules in those chains when firewalld makes changes.

In nftables, there's no fixed base chains - apps just define the base
chains they want. So in theory libvirt can define its own table and
chains without needing to worry about firewalld, as its chains will
be completely separate.

Looking at the syntax of 'nft' its quite different from iptables, so
libvirt support will require a completely new backend for nwfilter,
and adaptation to the virtual network firewall code. So that's a pretty
major amount of work and major testing impact.

> BTW: it's a bit shame that this nifty project hasn't received much more
> advertising. Looks cool so far.

I'd say the main blocker is the fact that you have to effectively
choose netfilter or nftables, as the compat layer is not good enough
to be used in the real world. This pretty much prevents distros from
using it by default until all apps are converted. IOW, the same kind
of reason why python2 still exists & is heavily, despite python3 being
around for years, except worse as at least with python both run in
parallel

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|