[CRIU] Checkpointing LXC with external bind mount plugin

[Pavel Emelyanov]

On 08/10/2014 10:54 AM, Yuto KAWAMURA wrote:
> 2014-08-08 23:54 GMT+09:00 Cyrill Gorcunov <gorcunov at gmail.com>:
>> On Thu, Aug 07, 2014 at 10:07:43PM +0900, Yuto KAWAMURA wrote:
>>> Hi,
>>>
>>> I'm doing little experiment of checkpointing a lxc container which has
>>> bind mounted pty from the host inside of it.
>>> As already noted somewhere, I know that the external bind mount of the
>>> lxc container can't be dumped without a plugin.
>>> I wrote a plugin handles paths which has major number UNIX98_PTY_SLAVE_MAJOR.
>>> After introduced this plugin, I'm not seeing an error such as
>>> "/dev/ttyX doesn't have a proper root mount" anymore, but still I'm
>>> getting an error:
>>>
>>>   Error (tty.c:222): tty: Unexpected format on path /dev/tty1
>>>
>>
>> Not sure about mount points, hopefully Andrew answer this part,
>> but for tty -- we expect pty to live on
>>
>> #define PTS_FMT"/dev/pts/%d"
>>
>> iirc lxc containers require special tricks for console. Take a look on
>>
>> http://criu.org/LXC
>> https://lists.linuxcontainers.org/pipermail/lxc-devel/2013-November/006329.html
>>
>> would it help?
>>
> 
> Right, I know this restriction for the LXC container, but in my
> understanding it is possible to dump a pts bind mount inside a
> container if I provide a proper plugin which handles it.
> WRT example of external bind mount
> plugin(http://git.criu.org/?p=criu.git;a=blob;f=test/mounts/ext/ext-mount.c;h=3ad3b25b4ce377189e9f0b9f4c1c44bc6684fdcd;hb=HEAD),
> seems it has the responsibility to restore the mountpoint for the
> mount that will be restored, so the criu does not have to dump/restore
> the path of an external bind mountpoint.

As far as I understand from the logs, bind mount is handled, but the
file opened by a process -- is not. We should teach criu to understand
not only unix98 ptys (devpts), but also so called legacy ones.

> I think we need to provide a function to prevent dumping a path which
> was handled by a plugin, so then we could leave the responsibility of
> managing these files to the plugin.
> 
> I still need more advanced advice, but thanks anyway :)
> 
>>> I think this is because the path /dev/tty1 is still mounted after the
>>> plugin handled it, and judged as a character device in
>>> dump_one_file at files.c.
>>> The question is, how to avoid this error? or am I understanding
>>> something incorrect? or should I consider to make some changes to
>>> criu?
>>>
>>> I'm using the version HEAD of the criu git repository.
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
> .
>