<div dir="ltr">Pavel,<div><br></div><div>Actually the first attempt is working, albeit with a little help. So I don't think we need to _replace_ the entire path that is relative to the FS's root with what is passed to CRIU on the command line. We just need to find the missing part of the pathname and prepend it to the relative path.</div>
<div><br></div><div>Let's look at the following realistic example from Docker. Docker bind mounts the container's /etc/host as follows:</div><div><br></div><div>mount /var/lib/docker/containers/<ID>/hosts /var/lib/docker/vfs/dir/<ID>/etc/hosts<br>
</div><div><br></div><div>The container's root is at /var/lib/docker/vfs/dir/<ID>. For container's /etc/hosts, CRIU records /containers/<ID>/hosts as source during dump. On restore, CRIU already has the container's root and ./etc/hosts within it, so all it needs is the leading /var/lib/docker for external bind mount. In other words, there is no need replacing the entire path which is --by the way-- dynamically generated for each container and not always easy to figure out.</div>
<div><br></div><div>Does it make sense?</div><div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 8:10 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">So, the 1st attempt with modifying original mount points roots is<br>
not working since the paths we see in /proc and dump are relative<br>
to the FS's root, not relative to global (well, CRIU's) root.<br>
<br>
That said, we can try to go another route and here it is.<br>
<br>
On dump we use one or more --ext-mount option with A=B arguments.<br>
A denotes a mountpoint (as seen from the target mount namespace)<br>
criu dumps and B is the string that will be written into the<br>
image file instead of the mountpoint's root. E.g. if we have a<br>
/foo/bar bind mounted into container under /x name, then the<br>
--ext-mount /x=foobar option will tell criu, that /x is a mount<br>
point with external source and it should write "foobar" into image<br>
instead of the path read from /proc.<br>
<br>
On restore we use the same --ext-mount option(s) with similar<br>
A=B arguments, but this time criu treats A as string from the<br>
image's root field (foobar in the example above) and B as the<br>
path in criu's mount namespace the should be bind mounted into<br>
the mountpoint.<br>
<br>
For example, let's again imagine we have /foo/bar bind mounted<br>
into container under /x name and /foo/bar is inaccessible from<br>
this container.<br>
<br>
On dump we say --ext-mount /x=foobar and mountpoints.img will<br>
contain a mountpoint with root=foobar and mountpoint=/x. On restore<br>
we use --ext-mount foobar=/foo2/bar option. This will result the<br>
/foo2/bar from criu's namespace get bind-mounted to /x inside the<br>
container we restore.<br>
<br>
<br>
Thanks,<br>
Pavel<br>
_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
</blockquote></div><br></div>