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

[Saied Kazemi]

I think there are two issues here:

1) You're right that dump and restore has to be handled by Docker so that
it can correctly keep track of container states.  Otherwise, it would think
that the container has exited when we do criu dump and would not know that
the container has resumed when we do criu restore.  Therefore, external
bind mounts can be addressed by Docker.  That said, because Docker
currently has no notion of dump and restore, we were trying to see how far
CRIU can go on its own (with additional command line options such as
--ext-mount) without requiring support from Docker.  Once we know that, we
can send specific requirements to the Docker community for implementation.

2) Putting Docker aside, it's possible to set up containers just by
executing a small program or shell script.  The issue here is how to get
CRIU to successfully dump and restore such a container.

As Pavel has shown in his examples, the problem is non-trivial.  One option
to limit the scope of the problem is by starting from the Docker side and
not worrying about CRIU's ability to dump and restore arbitrary containers.

--Saied




2)


On Fri, Jun 6, 2014 at 5:47 AM, Andrew Vagin <avagin at parallels.com> wrote:

> On Thu, Jun 05, 2014 at 05:12:36PM -0700, 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.
>
> I'm afraid that we are trying to solve the problem, which doesn't exist.
> Docket knows about all external bind-mounts, it can easy generate
> arguments for each mounts independently on their lengths, can't it?
>
> Who executes "criu restore"? I belive docker should do this, or am I
> mistaken? If I am not, I don't see a problem to generate arguments for
> each ext-mounts.
>
> Sorry if I don't understand something.
>
> >
> > --Saied
> >
> >
> >
> > On Thu, Jun 5, 2014 at 10:05 AM, Filipe Brandenburger <
> filbranden at google.com>
> > wrote:
> >
> >     On Thu, Jun 5, 2014 at 9:57 AM, Pavel Emelyanov <xemul at parallels.com
> >
> >     wrote:
> >     >> The --ext-mount parameter could also take the name of a file with
> a
> >     >> set of directory mappings, which might be easier to maintain than
> two
> >     >> tokens with a magic separator between them...
> >     >
> >     > Not sure I understand this, can you elaborate?
> >
> >     Something like --ext-mount /path/to/mappingfile and then have
> >     mappingfile use a format that makes it possible to list a number of
> >     mappings (no need for repeated options) and with no restrictions on
> >     the characters found in the path names (i.e. can handle paths with
> "="
> >     or ":" in them.)
> >     _______________________________________________
> >     CRIU mailing list
> >     CRIU at openvz.org
> >     https://lists.openvz.org/mailman/listinfo/criu
> >
> >
>
> > _______________________________________________
> > CRIU mailing list
> > CRIU at openvz.org
> > https://lists.openvz.org/mailman/listinfo/criu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140606/e423db65/attachment-0001.html>