[CRIU] Network unlock issue when checkpointing with -R

[Frederico Araujo]

Hi Andrey,

Thanks for your reply. To give you more details about my scenario, I'm live
cloning Apache between two hosts with same configuration. In my intended
scenario, I want to leave the original Apache running (that's why I use
-R). Currently, my steps for cloning are checkpoint -R on the source host,
transfer images between source and destination, and restore on the
destination host. I extended my copy of CRIU to handle relocation of
established connections when restoring on the destination host (otherwise,
the restore would fail in the destination host while trying to restore
established connections).

So, my first question: assuming that I'm not planning to execute restores
of Apache on the source host (I want it to be always running and want to be
able to take dumps of it to clone to another host), should I perform a full
checkpoint-restore cycle on the source host each time I want to clone
Apache or may I safely use checkpoint with option -R followed by a iptables
flush?

When you mentioned that -R doesn't work, is there other issues apart from
the issue related to established connections unlocking on the source host?

Thanks,
Fred

On Wed, Oct 30, 2013 at 4:39 AM, Andrew Vagin <avagin at parallels.com> wrote:

> On Tue, Oct 29, 2013 at 05:20:03PM -0500, Frederico Araujo wrote:
> > Hi there,
> >
> > I noticed that when checkpointing with the option -R, the iptables
> filters are
> > not being cleaned. I checked CRIU's log and this is what i have:
>
> -R doesn't work and it's known issue. In one moment we decided that this
> option is meaningless, because this options doesn't give a garanty that
> the created snapshot will be able to be restored in a future. For example
> if
> you checkpoint apache, you need to create a snapshot of all files, which
> apache is used in this moment. CRIU can't unlock TCP connections after
> dumping, because most probably they will be restored incorrectly and so on.
>
> Then we added the post-dump action script, where a user can do
> additional actions and then he can decide to stop or resume processes.
>
> You can look at test/zdtm.sh and test/post-dump.sh for example.
>
> >
> > ...
> > pie: 1067: Restored
> > (00.059424) Unlock network
> > (00.059454) Running iptables [iptables -t filter -D INPUT --protocol tcp
> > --source 10.0.3.1 --sport 50373 --destination 10.0.3.236 --dport 8080 -j
> DROP]
> > iptables: Bad rule (does a matching rule exist in that chain?).
> > (00.062168) Error (util.c:574): waitpid() failed: No child processes
> > (00.062193) Error (netfilter.c:69): Iptables configuration failed: No
> child
> > processes
> > (00.062204) Running iptables [iptables -t filter -D OUTPUT --protocol tcp
> > --source 10.0.3.236 --sport 8080 --destination 10.0.3.1 --dport 50373 -j
> DROP]
> > iptables: Bad rule (does a matching rule exist in that chain?).
> > ...
> >
> > Then, I checked my iptables after checkpointing and the exact rules are
> in
> > there. I manually executed the above iptables commands after
> checkpointing and
> > it successfully cleans the filters. Is this a known issue/bug or am doing
> > something wrong?
>
> You must understand that if you unlock tcp connections, they probably
> will not restored correctly in the next time. You can do that safely only
> if both side of a connection has been dumped.
>
> >
> > I'm using criu to checkpoint a instance of Apache Server. To reproduce
> the
> > scenario, you have to have an established connection to the server.
>
> Do you want to reproduce the state of tcp connections? Do you checkpoint
> both sides of connections?
> Can you give a bit more details about the use case?
>
> Thanks,
> Andrey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20131030/4982921b/attachment.html>