[CRIU] Another attempt at migration processes

[Adrian Reber]

On Tue, Jul 03, 2012 at 12:12:00PM +0400, Pavel Emelyanov wrote:
> 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?

No reason, I just wanted to implement the receiving side, then talk to
you if it is a reasonable approach and then implement it in 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

Sure, this was just for easier debugging.

> 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.

Okay.

> > 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.

I was doing that, but probably I did something wrong.

I will try to clean up my code and will start sending smaller patches to
the list to prepare the code for migration. Okay?

		Adrian