[CRIU] Remote lazy-restore design discussion

[Adrian Reber]

On Mon, Apr 04, 2016 at 07:20:33PM +0300, Mike Rapoport wrote:
> If I'd summarize my thoughts, I'd say I still don't see a clear picture of
> overall post-copy implementation :)
> I'll try to do some more homework and I'll try to somehow put the puzzle
> pieces together. 
> 
> > -- Pavel
> 
> >From 9dcc0588776c2974e698f651211472fcbb6bfc76 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt at linux.vnet.ibm.com>
> Date: Mon, 4 Apr 2016 17:50:13 +0300
> Subject: [UGLY PATCH] allow fetching pages from remote page-server
> 
> ---
>  criu/cr-restore.c         |   5 +-
>  criu/crtools.c            |   4 ++
>  criu/include/cr_options.h |   1 +
>  criu/include/page-read.h  |   6 ++
>  criu/include/page-xfer.h  |   7 ++
>  criu/page-read.c          |  49 ++++++++++++--
>  criu/page-xfer.c          | 163 +++++++++++++++++++++++++++++++++++++++++++++-
>  7 files changed, 227 insertions(+), 8 deletions(-)

Mike, thanks for sharing your patches. I was able to lazy restore a
process using your patches as the basis. I am now starting a page-server
and from there the uffd requested pages are retrieved. So right now I
have

 * source system:
    criu/criu page-server -D /tmp/4/ -v4 --port 27

 * destination system:
    criu/criu restore -D /dev/shm/3 -j -v4 --lazy-pages --lazy-address /tmp/userfault.socket

    criu/criu lazy-pages -v4 -D /dev/shm/3 --lazy-address /tmp/userfault.socket --page-client --address 192.168.122.3 --port 27

So a solution like this seems to work also. The nice thing about this
is, that in the uffd code I always only do pr.read_pages() and do not
have to think about network or not. I like this approach.

		Adrian