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

Saied Kazemi saied at google.com
Tue Jun 3 18:07:07 PDT 2014


Pavel,

Good news.  Making the following change to try_ext_bind_mount() after
applying your --ext-mount patches and using -M on dump and
-M/var/lib/docker on restore, it's possible to resume a Docker container
process _without_ any plugins.  Please note that as mentioned before, the
restore is successful as far as CRIU is concerned and is not visible to the
Docker daemon.

--Saied

diff --git a/mount.c b/mount.c
index eca3fa5..0f4a807 100644
--- a/mount.c
+++ b/mount.c
@@ -1174,22 +1174,32 @@ static int do_new_mount(struct mount_info *mi)

 static int try_ext_bind_mount(struct mount_info *mi)
 {
-       if (opts.ext_mount_mode == EXT_MOUNT_NONE) {
-              pr_err("Restoring external bind mount %s is not enabled\n",
-                              mi->mountpoint);
-              return -1;
-       }
+       char buf[256];
+       char *source;

-       if (opts.ext_mount_mode != EXT_MOUNT_OK)
-              return -1;
+       if (opts.ext_mount_mode == EXT_MOUNT_NONE) {
+               pr_err("Restoring external bind mount %s is not enabled\n",
+                       mi->mountpoint);
+               return -1;
+       }

-       pr_info("Bind-mounting %s to %s\n", mi->root, mi->mountpoint);
-       if (mount(mi->root, mi->mountpoint, NULL, MS_BIND, NULL)) {
-              pr_perror("Can't bind ext mount");
-              return -1;
-       }
+       if (opts.ext_mount_mode == EXT_MOUNT_PREP) {
+               snprintf(buf, 256, "%s/%s", opts.em_arg_1, mi->root);
+               source = buf;
+       } else
+               source = mi->root;
+
+       if (opts.ext_mount_mode != EXT_MOUNT_OK &&
+           opts.ext_mount_mode != EXT_MOUNT_PREP)
+               return -1;

-       return 0;
+       pr_info("Bind-mounting %s to %s\n", source, mi->mountpoint);
+       if (mount(source, mi->mountpoint, NULL, MS_BIND, NULL)) {
+               pr_perror("Can't bind ext mount");
+               return -1;
+       }
+
+       return 0;
 }



On Tue, Jun 3, 2014 at 1:44 PM, Saied Kazemi <saied at google.com> wrote:

> 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/fbae0546/attachment-0001.html>


More information about the CRIU mailing list