[CRIU] [PATCH 1/2] Re-create cgroups if necessary

[Pavel Emelyanov]

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
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. How would we
do it?

Thanks,
Pavel