[CRIU] [PATCH 1/2] Re-create cgroups if necessary
Serge Hallyn
serge.hallyn at ubuntu.com
Wed Jun 25 09:36:42 PDT 2014
Quoting Pavel Emelyanov (xemul at parallels.com):
> On 06/25/2014 07:55 PM, Serge Hallyn wrote:
> > Quoting Pavel Emelyanov (xemul at parallels.com):
> >> On 06/25/2014 07:06 PM, Serge Hallyn wrote:
> >>
> >>> Another complication, btw, will be to do with relative cgroup paths. I can
> >>> probably abstract that behind the cgmanager abstraction when I add that,
> >>> but idea is - if I checkpointed u1 on the host, in /cpuset/lxc/u1, and now
> >>> restart it inside a nested container, then it should be restarted at
> >>> /cpuset/lxc/somecontainer/lxc/u1, perhaps even /cpuset/lxc/u1/lxc/u1.
> >>
> >> How about do it two-step.
> >>
> >> First, on dump all cgroup paths are dumped relative to root task groups.
> >
> > What do you mean by 'root task groups'.
>
> The paths to cgroups where the init task lives. In criu code this
> task is referenced by root_task variable, so we call it root always :)
>
> > I would suggest: For each task, dump the cgroup path relative to the
> > init task being dumped.
>
> +1, this is what I'm suggesting. But this would be tightly affected by
> the hierarchy dump. The thing is -- in task image (the core.proto one)
> we don't keep paths. We keep the cg_set identifier, which refers to the
> set of cgroups from cgroup image, which in turn contain paths.
>
> > For the cgroup hierarchy, dump the path up to the dumping task's init's
> > cgroups.
>
> Exactly.
>
> > Then at restore, simply restore relative to the restoring path's init's
> > cgroups.
>
> Em... Not clear what you mean here. Let's imagine criu lives in / cgroups
If I'm pid 2048 and call criu to restore a task, criu looks at my init's
cgroups (pid 1's cgroups) and restores relative to that.
> always. The container you dump lives in e.g. /cpuset/lxc/ct1/ one. On
> restore you want to move it into /cpuset/foo/lxc/ct1/ one.
No, by default it would go to /cpuset/lxc/ct1, since my init task is in
cgroup /.
If I'm now restarting it in a container which is in /cpuset/lxc/ct3,
then it gets moved to /cpuset/lxc/ct3/lxc/ct1.
> How would we do it?
-serge
More information about the CRIU
mailing list