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

[Saied Kazemi]

On Tue, Jun 24, 2014 at 9:26 AM, Pavel Emelyanov <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).  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.  This is not something that it can handle at dump time.

--Saied
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140624/fb1fd335/attachment-0001.html>