[CRIU] Re: [PATCH 0/5] Add support to migrate processes

[Adrian Reber]

On Tue, Aug 21, 2012 at 08:34:54PM +0400, Pavel Emelyanov wrote:
> On 08/21/2012 07:20 PM, Adrian Reber wrote:
> > In order to migrate a process instead of writing the checkpoint
> > image to disk this patchset introduces the functionality to
> > listen on a network socket in the restore part to read the
> > checkpoint image over the network. Right now this works for
> > simple processes. To test this restore over the network
> > functionality the different image files are right now just piped
> > through netcat for the network transfer.
> > A future patchset will provide the functionality to directly dump
> > the checkpoint image to a network socket completely bypassing the
> > disk during checkpoint and restore.
> > 
> > Still not using the 
> >  # crtools dump -t 1234 | ssh root at restore.node crtools restore -t 1234
> > approach as I also see a value having it implemented the way
> > this patchset does it by opening a listen socket and waiting
> > for a checkpoint image to be transmitted.
> 
> Can you describe in more details what the value is?

Ah, tough question. First argument why I like it is because I wrote it ;-)

I see that the approach to pipe it through SSH make probably more sense
for most use cases, because you open only one connection and if you use
SSH it is already encrypted. If you do not need encryption it should be
easy to use netcat (or something like that).

During development, however, the approach I am using is much easier.
Opening a connection for each checkpoint file/part makes debugging much
easier and I like the concept of starting the listen part on a machine
in preparation for a process migration which will happen somewhere in
the future but not right now.

I hope you can accept this approach. I would like to finish the
receiving part and then finally implement the sending part. Once this is
in place and working I would then implement the sending through a pipe
like

# crtools dump -t 1234 | ssh root at restore.node crtools restore -t 1234

Would this be an acceptable approach or are you completely against the
listen socket approach I implemented right now?

		Adrian