[CRIU] Network unlock issue when checkpointing with -R
Andrey Wagin
avagin at gmail.com
Wed Oct 30 09:48:29 PDT 2013
2013/10/30 Frederico Araujo <araujof at gmail.com>:
> 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?
No, you should not perform a full checkpoint-restore cycle. No, you
can not safely use the -R option.
You can use the post-dump script, which returns a negative exit code.
The negative exit code can be a magic number and you will know that
crtools returns this magic number in successful case.
I don't know should we fix the -R options or we can just remove it all.
Look at the following set of commans, it does execlty what do you want.
$ cat test/post-dump.sh
#!/bin/sh
[ "$CRTOOLS_SCRIPT_ACTION" == post-dump ] || exit 0
#
# Special code to inform zdtm that we're
# done and should proceed testing treating
# non-zero return as known case.
exit 32
$ criu dump --action-script post-dump.sh ....
$ [ $? -eq 32 ] && echo PASS || echo FAIL
>
> 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?
Yes. I can't remember why we decided to not fix the -R option. Pavel
or Cyrill, do you know a reason?
More information about the CRIU
mailing list