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

[Pavel Emelyanov]

On 06/25/2014 08:36 PM, Serge Hallyn wrote:
> 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.

Ah, I see. So we always recreate the same hierarchy structure relative
to wherever criu sits. That's fine.

Thanks,
Pavel