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

[Batalov Eugene]

Conceptually we're able to get the same state in criu gc as criu restore
gets.

I am agree about namespaces and network unlock. Our folk has missed this.

About link remaps and namespaces. This thing from patch looks like it
should working:

> + if (rfe->remap_type == REMAP_TYPE__LINKED) {
>  + if (open_remap_linked(rfi, rfe))
>  + {
>  + pr_err("open_remap_linked failed");
>  + return -1;
>  + }
>  +
>  + int mntns_root = mntns_get_root_by_mnt_id(rfi->remap->rmnt_id);
>  + if (!unlinkat(mntns_root, rfi->remap->rpath, rfi->remap->is_dir ?
> AT_REMOVEDIR : 0))




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

> On Mon, May 16, 2016 at 04:00:41PM +0300, Batalov Eugene wrote:
> > 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).
>
> Hm. Actually I wonder if this approach will work entirely.
> gc_prepare_namespace() just calls prepare_pstree() and
> prepare_mnt_ns(), which won't attach to the namespaces of the dumped
> (or restored) tasks, but instead creates entirely new namespaces and
> removes the files from there. It also doesn't (I don't think) setns to
> the right place when it does network_unlock, because nothing sets up
> the right network namespace.
>
> It seems like this mode also needs a -t option to attach to the right
> task that it should clean up, as well as the images directory. Does
> that make sense?
>
> Tycho
>
> > 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.
>



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