[CRIU] Restore into different cgroups

[Tycho Andersen]

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.

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

Tycho