[CRIU] [PATCHv2 1/2] net: add nftables c/r

[Andrei Vagin]

On Wed, Nov 13, 2019, 11:04 PM Kirill Gorkunov <gorcunov at virtuozzo.com>
wrote:

> On Wed, Nov 13, 2019 at 08:29:15PM -0800, Andrei Vagin (C) wrote:
> > On Wed, Nov 13, 2019 at 02:14:06PM +0000, Alexander Mikhalitsyn wrote:
> > > On Wed, 13 Nov 2019 00:45:20 -0800
> > > Andrei Vagin <avagin at gmail.com> wrote:
> > >
> > > > On Tue, Nov 12, 2019 at 07:06:42PM +0300, Alexander Mikhalitsyn
> wrote:
> > > > > From: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
> > > > >
> > > > > After Centos-8 nft used instead of iptables. But we had never
> supported nft rules in
> > > > > CRIU, and after c/r all rules are flushed.
> > > > >
> > > > > Path to nft tool can be changed via CR_NFTABLES environment
> variable
> > > > > similar to CR_IPTABLES.
> > > >
> > > >
> > > > Can we use libnftnl? This should be faster, because we will not need
> to
> > > > fork a new process and exec a binary.
> > > >
> >
> > > Good point, but we have some problems with that. Currently, when we do
> > > "nft list ruleset" it output have special format (that corresponds to
> > > formal grammar defined by (nftables/src/parser_bison.y)). It's not
> > > format that supported by libnftnl. Currently libnftnl supports only
> > > dumping ruleset in "command format" as a sequence of nft commands that
> > > describes current ruleset. But if we try to use this format on
> > > Checkpoint in CRIU, then we have a problems on Restore - we need to
> > > execute a lot (maybe) "nft ..." commands. In performance terms it may
> > > be even worse then as we doing now. Of course, we can grab this parser
> > > from nftables to CRIU, but it's a lot of code and then we need
> > > additional compile-time deps - Bison for example. I don't know what to
> > > choose... :)
> >
> > Maybe we can use this way:
> >
> > on dump:
> >   * create a netlink socket
> >   * send a request to list all rules
> >   * save raw netlink messages in an image file.
> >
> > on restore:
> >   * create a netlink socket
> >   * send netlink messages from the image file into the socket.
> >
> > "ip addr save" and "ip addr restore" work this way.
> > https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1552
> > https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1618
>
> Which implies to move in part of netlink protocol into criu.
> Personally I don't mind but to me this looks a bit complex.
> I would rather stick with not that fast but more reliable
> usage of exec'ing CR_NFTABLES and the we could try to
> implement builtin (netlink based) data fetch from
> the kernel.
>

I believe we already have all required parts of netlink in the criu code
base. And our experience with the iptable tool showed that tools are not
always reliable. I think it's worth to try to implement this and see how it
will looks like. I think it should not take more than an hour or two.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20191114/fb726f10/attachment.html>