[CRIU] [lxc-devel] LXC integration

[Serge Hallyn]

Quoting Pavel Emelyanov (xemul at parallels.com):
> >>> 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?

Right.  I don't know how you'd fill the buffers back in (assume that's
already a known how-to from openvz code), but I'd expect you could
simply create and open the ptys in the plugin and pass them to the
right children.

Please do cc: us on any code you come up with, I'd love to take a
look.  I've got a few unrelated bugs I need to slog through but really
would like to start testing criu with lxc when I make progress on
those.

-serge