Difference between revisions of "CGroups"

Revision as of 14:50, 19 August 2014

This page describes how CRIU manages CGroups.

Overview

When talking about C/R of CGroups info, we mean three things:

The groups tasks live in
The groups that exist and are visible by tasks
Mountpoints of "cgroup" file system

CRIU started supporting this info since version 1.3-rc1. Here's how it works.

CGroups tasks live in

CRIU defines a "set" of cgroups. A set is a per-controller list of paths where a task lives. If paths to groups for two tasks differ at least for one controller, they are considered to live in different sets.

For every set CRIU generates an ID, which is then stored in the task's core.tc.cg_set image. The set in which CRIU lives during dump is also generated and is saved in the inventory image. The set in which the root task lives in is also special -- every other set (except CRIU's one) is checked to contain only sub-dirs of the respective root task's set. Otherwise dump fails.

On restore each task is moved into the respective set. If task's set coincide with CRIU's one task isn't moved anywhere and remains in whatever cgroups CRIU restore was started.

CGroups that are visible by tasks

Other than CGroups collected with tasks there can be other groups in which no tasks live. To pick up those CRIU gets the root set and saves all the CGroups tree starting from it. This information is stored in the cgroup.controllers image. In the same place CRIU saves the properties of CGroups -- these are values read from CGroup configuration files. Note -- since CRIU starts from root set and scans the directories tree, all the paths in this section are also subdirs of the root set's.

In order to make CRIU handle this information on dump and restore one should specify the --manage-cgroups option.

Mountpoints of "cgroup" file system

If found in the list of mounts, CRIU would dump one, but only the "root" mount will work. If you bind-mounted some subgroups into container, CRIU dump would fail.

Restoring into different CGroups

The option syntax is --cgroup-root [<controller>:]/<path> and it only makes sense on restore. Without this option CRIU would restore tasks and groups that live in the subtrees starting from the root task's dirs. When this option is given, the respective controllers' will get restoring starting from the give path instead.

@@ Line 9: / Line 9: @@
 # Mountpoints of "cgroup" file system
-Here's how CRIU manages them.
+CRIU started supporting this info since version 1.3-rc1. Here's how it works.
 == CGroups tasks live in ==
-Starting from version 1.3-rc1 CRIU saves the information about CGroups each task lives in in the <code>core</code> image's <code>tc.cg_set</code> field. This is an ID of a "set" found in the <code>cgroup.img</code>'s <code>sets</code> section.
+CRIU defines a "set" of cgroups. A set is a per-controller list of paths where a task lives. If paths to groups for two tasks differ at least for one controller, they are considered to live in different sets.
-Set contains per-controller paths to groups. If a task changes at least one controller's path it is considered to live in different set.
+For every set CRIU generates an ID, which is then stored in the task's <code>core.tc.cg_set</code> image. The set in which CRIU lives during dump is also generated and is saved in the inventory image. The set in which the root task lives in is also special -- every other set (except CRIU's one) is checked to contain only sub-dirs of the respective root task's set. Otherwise dump fails.
-While dumping CRIU gets the set in which the root task lives. Any new set found later should contain only subdirs of the root's set.
+On restore each task is moved into the respective set. If task's set coincide with CRIU's one task isn't moved anywhere and remains in whatever cgroups CRIU restore was started.
+== CGroups that are visible by tasks ==
+Other than CGroups collected with tasks there can be other groups in which no tasks live. To pick up those CRIU gets the root set and saves all the CGroups tree starting from it. This information is stored in the <code>cgroup.controllers</code> image. In the same place CRIU saves the properties of CGroups -- these are values read from CGroup configuration files. Note -- since CRIU starts from root set and scans the directories tree, all the paths in this section are also subdirs of the root set's.
+In order to make CRIU handle this information on dump and restore one should specify the <code>--manage-cgroups</code> option.
+== Mountpoints of "cgroup" file system ==
+If found in the list of mounts, CRIU would dump one, but only the "root" mount will work. If you bind-mounted some subgroups into container, CRIU dump would fail.
+== Restoring into different CGroups ==
+The option syntax is <code>--cgroup-root [<controller>:]/<path></code> and it only makes sense on restore. Without this option CRIU would restore tasks and groups that live in the subtrees starting from the root task's dirs. When this option is given, the respective controllers' will get restoring starting from the give path instead.