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

[Pavel Emelyanov]

On 08/27/2012 04:35 PM, Adrian Reber wrote:
> 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).

telnet

> 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 don't see much difference between opening a listen socket in crtools
versus getting one from parent process in this scenario.

> 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

Can you finish this work so that we can look at the overall patchset and
decide whether we do need listening socket in crtools or we do not?

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

I do agree that we need migration ability via socket. I don't understand
the need for opening a socket in crtools.

> 		Adrian
> .
>