mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-07-22 09:39:13 +00:00
No description
blcrcheckpointcontainercontainerscriudmtcphighly-availablelinuxmemory-trackingmigrationparasitepost-copyrestoresnapshotsuspenduserfaultfdzero-downtime
Before the nsroot= mount option, we were just getting lucky because the
cgroup superblocks "matched" when inspecting them from userspace, so we
were actually getting a bind mount from the host when migrating from within
cgroup namespaces.
Instead, let's actually do a new (i.e. not a bind mount) for cgroup
namespaces. For this, we need two things:
1. to prepare the cgroup namespace (and thus the cgroups) before the mount
ns, so when the mount() occurrs it is relative to the right cgroup path.
2. not reject cgroup filesystems with no root. A cgroup ns mount looks
like:
223 222 0:22 /lxc/unpriv /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd,nsroot=/lxc/unpriv
i.e. it has /lxc/unpriv as its root, and thus doesn't look rooted to CRIU.
We use the fstype->parse hook to rewrite this root to /, since it
is handled by the cgroup ns infrastructure.
v2: add new fstype->munge hook, allowing fstypes to munge their parsed
mountinfo entries if they want to. this allows us to get rid of the
ugly hacks with FSTYPE__CGROUP everywhere in teh patch.
v3: s/fstype->munge/fstype->parse for FSTYPE__CGROUP
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
|
||
|---|---|---|
| contrib | ||
| crit | ||
| criu | ||
| Documentation | ||
| images | ||
| lib | ||
| scripts | ||
| test | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| COPYING | ||
| CREDITS | ||
| Makefile | ||
| Makefile.install | ||
| Makefile.versions | ||
| README.md | ||
CRIU (Checkpoint and Restore in Userspace)
An utility to checkpoint/restore tasks. Using this tool, you can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space.
The project home is at http://criu.org.
Pages worth starting with are:
- Kernel configuration, compilation, etc
- A simple example of usage
- More sophisticated example with graphical app
How to contribute
- How to submit patches;
- Send all bug reports to mailing list;
- Spread the word about CRIU in social networks;