[CRIU] Attempt for process migration

[Pavel Emelyanov]

On 03/06/2012 04:51 PM, Adrian Reber wrote:
> On Tue, Mar 06, 2012 at 04:00:41PM +0400, Pavel Emelyanov wrote:
>>> Now I looked into migrating one
>>> process from one machine to another. I written some code but before I am
>>> going to continue I wanted to ask if there has been already any
>>> discussion in that direction? 
>>
>> Not really. The plan is to do it similar to how we do it with the openvz -- we
>> just put the dump files locally and then copy them to the destination node
>> with plain scp (or use NFS for this).
>>
>> I actually planned to use the similar with criu, but I'm open for discussion.
> 
> We are interested in migrating processes in an HPC environment. We have
> shared storage on all our nodes (lustre, nfs) but we really want to
> avoid putting more pressure on the storage backend. Therefore we want to
> do it directly over sockets without any disk.

OK, this sounds reasonable.

>> The other thing around it is that the images files in criu are now considered
>> to be seek-able at the restore time which is not so for sockets, so your
>> approach will require more fixes on the restore code.
>>
>> The other problem with this set is that for every single image file we have
>> to set-up a TCP connection from the beginning. This is not very good, I suppose,
>> since typically image files are several bytes, thus the handshake latency will
>> kill all the performance.
> 
> That is why I am I right now only using one connection.

Hm... Yes, I overlooked that in the code :( But in that case you'll have problems
with determining images boundaries -- we don't know the image file size until
it's fully written...

>> The Cyrill's proposal about writing +1 abstraction level looks sane, we we'll also
>> have to integrate criu with openvz live migration which has its own image format.
> 
> It sounds like it is okay if I continue implementing it. I will look at
> implementing the abstraction level mentioned and what to do about
> restore without seeking. I will post my progress here and we can then
> decide if that is the right direction or if it needs to be done another
> way.

OK, thanks!

> 		Adrian
> .
>