[CRIU] Restore into different cgroups

[Serge Hallyn]

Quoting Tycho Andersen (tycho.andersen at canonical.com):
> Hi Pavel,
> 
> I don't think we've talked about it, but here are some thoughts.

We did, in a separate thread.  I'm afraid I forget the name of the
other gentleman involved (and the thread isn't in my criu mbox)

> 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.
> 
> > 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.

We need that code, if only to support changing nesting level.  Say we
checkpoint a container on the host.  Now we want to restart it inside
a container.  So now it's old cgroup path /lxc/c1 should become
/lxc/c2/lxc/c1.

> > 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.
> 
> Tycho