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

[Pavel Emelyanov]

On 06/24/2014 09:01 PM, Saied Kazemi wrote:
> 
> 
> 
> On Tue, Jun 24, 2014 at 9:26 AM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
> 
>     On 06/24/2014 06:12 PM, Serge Hallyn wrote:
> 
>     >> Yes. Emply cgroups cannot be discovered through /proc/pid/cgroup file,
>     >> we should walk the alive cgroup mount. But the problem is -- we cannot
>     >> just take the system /sys/fs/cgroup/ directories, since there will be
>     >> cgroups from other containers as well. We should find the root subdir
>     >> of the container we dump and walk _this_ subtree.
>     >
>     > I volunteer to work on a proper cgroup c/r implementation, once Tycho
>     > gets the very basics done.
> 
>     Serge, Tycho, I think I need to clarify one more thing.
> 
>     I believe, that once we do full cgroups hierarchy restore all the
>     mkdirs would go away from the move_in_cgroup() routine. Instead,
>     we will have some code, that would construct all the cgroup subtree
>     before criu will start forking tasks. And once we have it, the
>     move_in_cgroup() would (should) never fail. Thus this patch would
>     be effectively reversed.
> 
>     Thanks,
>     Pavel
> 
> 
> I agree.  Creation of the cgroup and its subtree should be done in one place as opposed
> to being split apart (i.e., between prepare_cgroup_sfd() and move_in_cgroup() as is done
> currently).
> 
> Regarding the 4 items to do for cgroups in your earlier email, I believe that we should
> have CLI options to tell CRIU what cgroups it needs to restore (almost like the way we
> tell it about external bind mounts). 

I was thinking that if we take the root task, check cgroups it lives in and
dump the whole subtree starting from it, this would work properly and would
not require and CLI hints.

Do you mean, that we need to tell criu where in cgroup hierarchy to start
recreating the subtree it dumped?

> This way we can handle the empty cgroups as well as dumping and restoring on the same
> machine versus on a different machine (i.e., migration).  For migration, CRIU definitely
> needs to be told how to handle cgroups name collision.

But if we ask criu to restore tasks in a fresh new sub-cgroup, why would this
collision happen?

> This is not something that it can handle at dump time.
> 
> --Saied
> 

Thanks,
Pavel