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

Pavel Emelyanov xemul at parallels.com
Fri Jun 6 01:11:44 PDT 2014


On 06/06/2014 04:12 AM, Saied Kazemi wrote:
> You're right about /fs1 /fs2 example above, it can get pretty convoluted.
> 
> Regarding Docker container IDs, they are generated when new containers (along
> with their new filesystems) are created.  For dump/restore, however, we need 
> to keep the same container ID and preserve the state of its filesystem.  This 
> requires Docker changes.  My comment was about the difficulty of specifying
> long container root pathnames as command line arguments to CRIU.  You'd have
> to first find the ID through docker ps and then provide it in full (64 characters)
> in addition to the leading /var/lib/docker/vfs/root/ string.  So recording the
> container ID during dump, as it's currently, done is advantageous.

Tricky... Thinking aloud.

Let's consider we have two boxes, one with /var sitting on the same disk
with /, and the other one having /var being mounted from another disk.
Then we have two docker containers on both and for each we have a file
/var/lib/docker/container/ID/hosts bind mounted into containers'
/etc/hosts file (which is /var/lib/docker/vfs/dir/ID/etc/hosts on host).

If we dump these two with keeping what we see from kernel we'd have the

  /var/lib/docker/container/ID/hosts -> /etc/hosts

record on the first node and the

  /lib/docker/container/ID/hosts -> /etc/hosts

one on the second, where the 2nd one is trimmed due to /var being a mount
point on that box and this is what kernel would report us.

When we restore we'll have to know from which node the images came from
to find out whether we need to modify the paths somehow...

Thanks,
Pavel


More information about the CRIU mailing list