[CRIU] Restore into different cgroups
Serge Hallyn
serge.hallyn at ubuntu.com
Tue Aug 12 10:11:29 PDT 2014
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.
More information about the CRIU
mailing list