[CRIU] [RFC][PATCH 0/3] Proposal for native (w/o plugins) support for external bind mounts

[Saied Kazemi]

Hi Pavel,

It'd make using CRIU much easier :)  For now, I've been using a Docker
plugin in my experiments to dump and restore a process inside a Docker
container:

1. On the dump side, I am passing m->root to the Docker plugin (in addition
to m->mountpoint and m->mnt_id) so that the path can be recorded in the img
file.

        ret = cr_plugin_dump_ext_mount(m->root, m->mountpoint + 1,
m->mnt_id);

2. On the restore side, I pass opts.root from --root on the command line
instead of always passing "/" (this was probably your original intention).
 Then the Docker plugin prepends /var/lib/docker to the path that was
recorded in the img file during dump.

        ret = cr_plugin_restore_ext_mount(mi->mnt_id, mi->mountpoint,
opts.root ? : "/", NULL);

Like the plugin in the run.sh example, the Docker plugin is using an
environment variable (CR_EXT_BIND_MOUNTS) to identify its files.  It'd be
great to get rid of this environment variable.

Finally, I have to manually set up the cgroups (e.g.,
/sys/fs/cgroup/cpu/docker/<ID>) before restoring:

        criu restore -o restore.log --root /var/lib/docker/vfs/dir/<ID> -D
img -v4 -j -n mnt -n pid --lib /path/to/plugin

The end result is that the process is successfully restored and resumes
operation.  Currently, however, the Docker daemon is totally unaware of the
process being resurrected and docker ps won't show it.  We need supporting
code in Docker.

--Saied






On Tue, Jun 3, 2014 at 9:26 AM, Pavel Emelyanov <xemul at parallels.com> wrote:

> Hi,
>
> I'd like to propose an API to support external mount points w/o plugins.
> It's a typical scenario when people just do a bind mount before going
> into chroot/pivot_root and starting a container. Such a construction is
> not dumpable by CRIU, but I think it's possibly to handle the common and
> typical scenario.
>
> That said, the proposal is to introduce the --ext-mount option with the
> syntax:
>
> --ext-mount without arguments on dump says, that mount point with the
> source sitting outside of the namespace root should be dumped "as is".
> On restore this will say to try create bind mount with unchanged source
> path. It's useful for suspend/resume scenario and for live-migration
> between hosts with identical FS paths.
>
> --ext-mount p<path>, e.g. --ext-mount p/foo on restore will cause the
> <path> be prepended to any bind mount source. IOW /bar bind mounted into
> /root will result in /foo/bar get bind mounted into /root on restore
>
> --ext-mount s<delim><path1><delim><path2>, e.g. --ext-mount s:/foo:/bar
> will case the <path1> prefix get substituted with <path2> prefix for
> every external bind mount on restore. IOW /foo/foobar bind mounted into
> /root will result in /bar/foobar bind mounted to /root on restore.
>
> The patchset is not complete, it just demonstrates the intention. Saied,
> it seems to handle your scripted case, the external file gets mounted into
> proper place with plain --ext-mount option, but there's still unresolved
> issue with proc :(
>
> Comments are welcome.
>
> TODO
>
> 1. check that flags (ro, shared) are dumped and restore correctly
> 2. implement p and s modes for --ext-mount option on restore
> 3. support ext-mount option in RPC API
> 4. add option help text and documentation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140603/e2dc9827/attachment.html>