[CRIU] Another attempt at migration processes

[Pavel Emelyanov]

On 07/02/2012 04:03 PM, Adrian Reber wrote:
> I have taken the code and changed it to allow migration. For this try I
> only changed the restore part to listen on a socket where it receives
> all the files needed for the restore process.
> 
> On the first host I am dumping the process and on the second host I am
> running crtools (with the attached patch applied) like this:
> 
> ./crtools restore -l 0.0.0.0:10000 -vvv -t 2920
> 
>   -l|--listen <ip:port>  listen on ip:port for incoming restore objects
> 
> On the first host I am still transferring the process image manually
> like this:
> 
> for i in pstree.img reg-files.img  remap-fpath.img pipes.img inetsk.img
> unixsk.img   sk-queues.img eventfd.img eventpoll-tfd.img eventpoll.img
> inotify.img inotify-wd.img vmas-2920.img fdinfo-2920.img pipes-data.img
> core-2920.img fs-2920.img sigacts-2920.img vmas-2920.img core-2920.img
> pages-2920.img  itimers-2920.img creds-2920.img mm-2920.img  eof ; do
> cat dump/$i | nc dest-host 10000 ; done

Why can't you send the images via socket right from the crtools?

> Using the attached patch I can "migrate" a process without copying all
> the files.

That's good news ;)

> The patch is still very rough and meant as an RFC to see if this is
> something criu is interested in and if the implementation in way like I
> did could be accepted by upstream?

Yes, we're interested in this type of migration, but the implementation
I see should be improved.

Two things should be fixes in the first step: 1. don't use printf-s, use
crtools logging engine 2. don't push the host/port/socket arguments all
over the code, try to reuse the open_image/cr_fdset_open engine to work 
with sockets.

> This only works for very simple test program and my biggest problem is
> that I have to write the pages*.img file to a temporary file (in
> /dev/shm) right now, because I was not able to open a network socket
> from restorer.c.

That's because restorer.c is not liked with glibc. You have to use bare
syscalls for that.

> 		Adrian