[lxc-devel] [CRIU] LXC integration

[Pavel Emelyanov]

>>> 1) Adding an argument to the criu restore command that will make it
>>> exec() a custom command when restore is complete. Thus, the newly
>>> created init process will become a child of this command. Then we could
>>> create a new lxc-start-like command that will take pid as an argument
>>> and work with it instead of the pid returned by clone(). This way LXC
>>> will be able to intercept the SIGCHLD signal from the restored init
>>> process on container shutdown/restart and also send appropriate signals.
>> Yup, this is exactly the way #1 I've described above :) And it looks like
>> this one will be the final one, as the way #2 cannot be implemented when
>> criu runs ar RPC service.
>>
>> Deyan, do you have some code doing this ready? We'd be happy if you could
>> participate in LXC support development.
> 
> I still don't have any code on this as I wanted a second opinion before
> working on it but I'll start implementing it right away.

Cool!

>>> 2) Currently /dev/console and /dev/ttyX in the container are actually
>>> bind-mounted /dev/pts/Y files. I've been thinking about adding code that
>>> creates master-slave pty pairs when restoring mount-points and
>>> bind-mounts them to the /dev/ttyX files. After that, with a small patch
>>> to the tty.c file we'll be able to use the already allocated slaves,
>>> while the lxc-start-like command from 1) will get the masters' open file
>>> descriptors upon exec().
>> Absolutely. But the code should be implemented as plugin.
> 
> I wrote a simple plugin that handles the external tty/console mounts by
> simply doing nothing. It was just a test out of curiosity. Unfortunately
> to get it to successfully dump the container and later restore it I had
> to make a few changes to tty.c - we still end up there because we have
> pts files opened.
> 
> Do you have any idea of how should I get around this using only a plugin?

Hm... If we properly restore the /dev/console and /dev/tts in plugin, then
existing tty restoring code should just pick those up. Can you shed more
light on what problems you have with ptys?

> Maybe implement another plugin hook for restoring external ttys and call
> this from tty.c?
> 
>>
>>> Before actually beginning with the implementation I'll be glad to hear
>>> what you think about these solutions. Also, I'm open to any other
>>> suggestions or improvement ideas.
>> Everything seems to be in sync with what we plan to do. I think, that even if
>> you start doing the criu->exec->lxc reattach thing, you wouldn't conflict with
>> Andrey, as he's looking more into the live-migrating LXC container with P.Haul.
> 
> Great, I will start from the criu->exec->lxc implementation.

That's awesome! Don't hesitate to ping us via e-mail if you need help.

Thanks,
Pavel