[CRIU] implementing some kind of --leave-frozen option for c/r in CRIU

Batalov Eugene eabatalov89 at gmail.com
Mon May 16 06:00:41 PDT 2016


Hello.

The idea of Pavel to reuse part of "restore: restore freezer cgroup state"
patch looks good and simple.

About networking unlock. Yes. There is a work in progress on new criu gc
command.
You can find patch commit here:
https://github.com/AuthenticEshkinKot/criu/commit/2ab52fec7a05f9792c871709758d14137fe9f379

The main problem with it is the fact that network unlock and link remaps
cleanup logic
is coupled with logic of criu restore command. And criu restore logic is
not trivial.
So we're trying to carefully reduce the amount of code in CRIU gc. We need
to reuse CRIU restore command code and need not to introduce ugly hacks and
excessive CRIU restore code dependencies (this dependence would limit CRIU
restore code changes at the same time).

GRIU gc both able print what's left in the system after dump (iptables,
link remaps) and to cleanup this stuff too.


2016-05-16 15:31 GMT+03:00 Pavel Emelyanov <xemul at virtuozzo.com>:

> On 05/10/2016 08:04 PM, Tycho Andersen wrote:
> > Hi guys,
> >
> > I'm looking at implementing some kind of --leave-frozen option in
> > CRIU, so that we can have a basic UX in LXD where we can wait for the
> > restore to be successful before we kill the checkpointed container. I
> > know p.haul does this by just using a callback, but it would be sort
> > of painful to absorb just the callback part without doing a lot of
> > extra engineering. We'll get LXD using p.haul someday, though :)
> >
> > The actual --leave-frozen patch is not so bad (see attached), but I'm
> > not sure what to do about the network locking/unlocking bits.
>
> There was a patch 8b04551c (restore: restore freezer cgroup state) in 2.0
> that turned cgroup into whatever state it was before dump. Can it be fixed
> to make '--leave-frozen' alter the behavior of
> add_freezer_state_for_restore()
> and set it to 'frozen' always?
>
> > It seems like it is always safe to do the bits in
> > cpt_unlock_tcp_connections() since that's just disabling tcp repair
> > mode, but all of the iptables rules seem necessary in order to keep
> > the network locked.
> >
> > So my question is: is there a nice way we can "tag" these rules so
> > that something can come by and delete them later? I was thinking about
> > having criu add a comment (via -m comment --comment "CRIU-LOCK-RULE")
> > to each rule it adds, but I'm not sure if there's a better way, or if
> > I've missed something entirely.
>
> Yes, there's an issue #45 -- show what's left in the system after dump.
> Iptables
> rules are in the list :) I know that some gentlemen (Cc) from
> Saint-Petersburg were
> interested in implementing it in form of 'criu gc' action, so probably
> tuning this
> option to support '--show-only' would help you?
>
> > Thanks!
> >
> > Tycho
> >
> >
> >
> > _______________________________________________
> > CRIU mailing list
> > CRIU at openvz.org
> > https://lists.openvz.org/mailman/listinfo/criu
> >
>
>


-- 
Best regards,
Eugene Batalov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160516/56001135/attachment-0001.html>


More information about the CRIU mailing list