[CRIU] Restore into different cgroups

[Serge Hallyn]

Quoting Pavel Emelyanov (xemul at parallels.com):
> On 08/12/2014 06:42 PM, Tycho Andersen wrote:
> > Hi Pavel,
> > 
> > I don't think we've talked about it, but here are some thoughts.
> > 
> > On Tue, Aug 12, 2014 at 06:22:59PM +0400, Pavel Emelyanov wrote:
> >> Serge, Tycho,
> >>
> >> Some time ago we've discussed that it would be good to have an
> >> ability to dump a container sitting in cgroups e.g. /memory/lxc/0/
> >> but to restore one into some different path e.g. /memory/foo/lxc/0/.
> >>
> >> We're having similar issue in OpenVZ -- while migrating the container
> >> we can request for its ID change and thus we will need to change
> >> cgroup paths e.g. from /memory/vz/100 into /memory/vz/101.
> > 
> > For reference, LXC uses a slightly different scheme of testing whether
> > /memory/lxc/$container_name exists, and moving on to
> > /memory/lxc/$container_name-%d where %d is some fresh number:
> > https://github.com/lxc/lxc/blob/master/src/lxc/cgmanager.c#L517
> > 
> > I assume we'd do something similar if we implement a
> > --create-fresh-cgroups option in lxc-restore, so any CRIU re-writing
> > scheme would ideally support both cases.
> 
> Can it happen, that you dump from /lxc/ctname-1 but restore into 
> /lxc/ctname-2? So that the path is not just $old + suffix.
> 
> >> I've noticed that currently all the paths in the cgroup image contains
> >> only absolute paths which makes cgroup dir (actually root) change
> >> quite tricky.
> > 
> > This is mostly just an artifact of me being lazy. It would have taken
> > more (unnecessary at the time) code to split each path segment out in
> > the tree. I don't mind writing this code if it is ultimately decided
> > to be necessary, though.
> > 
> >> While I'm thinking what can be done about it, maybe you have already
> >> researched this and have some idea ready?
> > 
> > I guess the easiest thing is perhaps some regex-rewriting option, e.g.
> > --rewrite-cgroups='s/100/101' or something? We'd want to avoid
> > rewriting everything since the container may be in non-container
> > related cgroups.
> 
> Doing regexp substitution in criu code would be confusing... I was 
> thinking about treating all the paths as being relative to the init 
> task's cgset and keep this task's full paths in the image. Then

Yes, please.

> introduce the --cgroup-root option that would override the init task's
> path from the image.
> 
> Would that work for you?
> 
> Tanks,
> Pavel
>