<div dir="ltr">Hi Pavel,<div><br></div><div>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:</div><div><br></div>
<div>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.</div><div><div><br></div><div> ret = cr_plugin_dump_ext_mount(m->root, m->mountpoint + 1, m->mnt_id);</div>
</div><div><br></div><div>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.</div>
<div><br></div><div> ret = cr_plugin_restore_ext_mount(mi->mnt_id, mi->mountpoint, opts.root ? : "/", NULL);</div><div><br></div><div>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.</div>
<div><br></div><div>Finally, I have to manually set up the cgroups (e.g., /sys/fs/cgroup/cpu/docker/<ID>) before restoring:</div><div><br></div><div><div> criu restore -o restore.log --root /var/lib/docker/vfs/dir/<ID> -D img -v4 -j -n mnt -n pid --lib /path/to/plugin</div>
</div><div><br></div><div>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.</div>
<div><br></div><div>--Saied</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 9:26 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'd like to propose an API to support external mount points w/o plugins.<br>
It's a typical scenario when people just do a bind mount before going<br>
into chroot/pivot_root and starting a container. Such a construction is<br>
not dumpable by CRIU, but I think it's possibly to handle the common and<br>
typical scenario.<br>
<br>
That said, the proposal is to introduce the --ext-mount option with the<br>
syntax:<br>
<br>
--ext-mount without arguments on dump says, that mount point with the<br>
source sitting outside of the namespace root should be dumped "as is".<br>
On restore this will say to try create bind mount with unchanged source<br>
path. It's useful for suspend/resume scenario and for live-migration<br>
between hosts with identical FS paths.<br>
<br>
--ext-mount p<path>, e.g. --ext-mount p/foo on restore will cause the<br>
<path> be prepended to any bind mount source. IOW /bar bind mounted into<br>
/root will result in /foo/bar get bind mounted into /root on restore<br>
<br>
--ext-mount s<delim><path1><delim><path2>, e.g. --ext-mount s:/foo:/bar<br>
will case the <path1> prefix get substituted with <path2> prefix for<br>
every external bind mount on restore. IOW /foo/foobar bind mounted into<br>
/root will result in /bar/foobar bind mounted to /root on restore.<br>
<br>
The patchset is not complete, it just demonstrates the intention. Saied,<br>
it seems to handle your scripted case, the external file gets mounted into<br>
proper place with plain --ext-mount option, but there's still unresolved<br>
issue with proc :(<br>
<br>
Comments are welcome.<br>
<br>
TODO<br>
<br>
1. check that flags (ro, shared) are dumped and restore correctly<br>
2. implement p and s modes for --ext-mount option on restore<br>
3. support ext-mount option in RPC API<br>
4. add option help text and documentation<br>
</blockquote></div><br></div>