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

[Batalov Eugene]

>
> What I'm not sure about is how this works with
> --leave-running; doesn't it already delete these rules? If not, how is
> the network actually unlocked?


cr-dump.c: (opts.final_state == TASK_ALIVE if --leave-running is passed to
criu)
1597     if (ret || post_dump_ret || opts.final_state == TASK_ALIVE) {
1598         network_unlock();
1599         delete_link_remaps();
1600     }

The only problem is that this 2 function calls are executed after dump and
during restore.
And this calls expect already initialized big c/r state. It's the problem
that I've described in the previous email.

Also there is a pecularity in criu gc that can be important for you. You
need to specify path to image
files dir for criu gc because criu gc uses data from images to find the
right iptable rules and link remaps.
So a part of dump should be stored on node you migrate from.

Tycho, do you have any urgency in criu gc feature arrival?


2016-05-16 17:17 GMT+03:00 Tycho Andersen <tycho.andersen at canonical.com>:

> On Mon, May 16, 2016 at 03:31:57PM +0300, Pavel Emelyanov wrote:
> > 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?
>
> That's basically what this patch does, although in a slightly
> different way than what you suggest. I can fix it up if you want to
> apply it, though.
>
> > > 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?
>
> Well, I could use `criu gc` directly to remove the iptables rules to
> unlock the network if that's all that was needed. So I don't really
> need a --show-only. What I'm not sure about is how this works with
> --leave-running; doesn't it already delete these rules? If not, how is
> the network actually unlocked?
>
> I don't mind implementing such a `criu gc` option where it tries to go
> through and delete its rules, though. That sounds like exactly what I
> want here, and if it's ok with you, I can try to work on it :)
>
> Tycho
>



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