[CRIU] LXC integration
Deyan Doychev
deyan at 1h.com
Mon Mar 17 14:35:58 PDT 2014
Hello everybody!
For the last few weeks I've been trying to dump LXC containers with
CRIU. Everything seems to work just fine when there are no consoles
inside the containers. I can dump the init process and the whole process
tree of the container and restore it later. I'm able to add the
processes to the right cgroup and fix host side network configuration
with an action script.
However the following two problems are present:
1) After restoring the previously dumped container, LXC doesn't know
about it and all the LXC commands claim it is stopped. This is normal
since there is no lxc-start-like process on top with its socket and main
loop.
2) I have containers that need their consoles and a working lxc-console
command.
Currently I have the following ideas for fixing these problems:
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.
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().
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.
Regards,
Deyan Doychev
More information about the CRIU
mailing list