[CRIU] Restore into different cgroups

[Pavel Emelyanov]

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
introduce the --cgroup-root option that would override the init task's
path from the image.

Would that work for you?

Tanks,
Pavel