[CRIU] Restore into different cgroups

[Tycho Andersen]

On Wed, Aug 13, 2014 at 11:59:30PM +0400, Pavel Emelyanov wrote:
> On 08/13/2014 06:03 PM, Tycho Andersen wrote:
> > Hi Pavel, Serge,
> > 
> > On Tue, Aug 12, 2014 at 05:11:29PM +0000, Serge Hallyn wrote:
> >> Quoting Pavel Emelyanov (xemul at parallels.com):
> >>> On 08/12/2014 07:13 PM, Tycho Andersen wrote:
> >>>
> >>>>> 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?
> >>>>
> >>>> I don't understand exactly how that would work. It would just add a
> >>>> prefix, so --cgroup-root=/foo would rewrite /lxc/u1 to /foo/lxc/u1?
> >>>> What about other cgroups unrelated to the container? Can we avoid
> >>>> rewriting those?
> >>>
> >>> OK, let me explain in more details what I mean.
> >>>
> >>> Let's imagine we have init task living in /lxc/ct, some other task
> >>> in /lxc/ct/sub and there's also an empty subgroup /lxc/ct/empty.
> >>>
> >>> When we dump this, in the image we'd get:
> >>>
> >>> * root task lives in /lxc/ct
> >>> * "some other task" lives in /sub
> >>> * there's a subgroup called /sub
> >>> * there's a subgroup called /empty
> >>>
> >>> On restore criu would prepend the /lxc/ct (path from root task)
> >>> to whatever path it meets in the cgroup image.
> >>>
> >>> If we want to restore tasks into /lxc/ct2/lxc/ct, then we'd say on
> >>> restore --cgroup-root /lxc/ct2/lxc/ct and criu would prepend _this_
> >>> to all the other paths (except for the root task's, i.e. /lxc/ct
> >>> from the image would be ignored).
> >>>
> >>> This will be so for every controller. Do we need per-controller
> >>> control? If can look like
> >>>
> >>> --cgroup-root $path -- prepend $path for every controller
> >>> --cgroup-root $ctl:$path -- only for controller $ctl
> >>>
> >>> and the option can be specified multiple times.
> >>
> >> Again, sounds good to me.  The code shouldn't be bad, just
> >> grab /proc/1/cgroup contents at start, and then index into
> >> each tasks' cgroup (ensuring that it lives under the init
> >> tasks' cgroup, which i think you're already doing) to get
> >> the sub-cgroup to checkpoint.
> > 
> > I see, combined with the patch Pavel sent this morning and a good
> > sleep this makes more sense now. Pavel, are you implementing this or
> > would you like me to?
> 
> I would greatly appreciate if you do on top of what's now on the
> mailing list.

Ok, I will work on a patch.

> > The only other question I have is what to do about cgroups where we
> > don't want to reset the root (e.g. the user.slice systemd groups,
> > presumably).
> 
> I think we can do it like
> 
>     --cgroup-root /new-root --cgroup-root name=systemd:/$orig_root
> 
> The first option would set the root for all, the 2nd would then
> override it for name=systemd one. $orig_root should be the proper
> path, but maybe for convenience we can reserve some keyword, like
> ORIG.
> 
> Does this make sense?

Yes, it does. (I assume that if it is unspecified it stays the same,
i.e. if there is only --cgroup-root name=systemd:/new-root, that
everything else has the same root.)

Tycho