Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Process Migration using Sockets (p1)
This patch introduces the --remote option and the necessary code changes to support it. This leaves user the option to decide if the checkpoint data is to be stored on disk or sent through the network (through the image-proxy). The latter forwards the data to the destination node where image-cache receives it. The overall communication is performed as follows: src_node CRIU dump -> (sends images through UNIX sockets) -> image-proxy | V dst_node: CRIU restore <- (receives images through UNIX sockets)<- image-cache Communication between image-proxy and image-cache is done through a single TCP connection. Running criu with --remote option is like this: dst_node# criu image-cache -d --port <port> -o /tmp/image-cache.log dst_node# criu restore --remote -o /tmp/image-cache.log src_node# criu image-proxy -d --port <port> --address <dst_node> -o /tmp/image-proxy.log src_node# criu dump -t <pid> --remote -o /tmp/dump.log [ xemul: here's the list of what should be done with the cache/proxy in order to have them merged into master. 0. Document the whole thing :) Please, add articles for newly introduced actions and options to https://criu.org/CLI page. Also, it would be good to have an article describing the protocols involved. 1. Make the unix sockets reside in work-dir. The good thing is that we've get rid of the socket name option :) But looking at do_open_remote_image() I see that it fchdir-s to image dir before connecting to proxy/cache. Better solution is to put the socket into workdir. 1a. After this the option -D|--images-dir should become optional. Provided the --remote is given CRIU should work purely on the work-dir and not generate anything in the images-dir. 2. Tune up the image_cache and image_proxy commands to accept the --status-fd and --pidfile options. Presumably the very cr_daemon() call should be equipped with everything that should be done for daemonizing and proxy/cache tasks should just call it :) 3. Fix local connections not to generate per-image threads. There can be many images and it's not nice to stress the system with such amount of threads. Please, look at how criu/uffd.c manages multiple descriptors with page-faults using the epoll stuff. 3a. The accept_remote_image_connections() seem not to work well with opts.ps_socket scenario as the former just calls accept() on whatever socket is passed there, while the opts.ps_socket is already an established socket for data transfer. 4. No strings in protocol. Now the hard-coded "RESTORE_FINISH" string (and DUMP_FINISHED one) is used to terminate the communication. Need to tune up the protobuf objects to send boolean (or integer) EOF sign rather that the string. 5. Check how proxy/cache works with incremental dumps. Looking at the skip_remote_bytes() I think that image-cache and -proxy still do not work well with stacked pages images. Probably for those we'll need the page-server or lazy-pages -like protocol that would request the needed regions and receive it back rather than read bytes from sockets simply to skip those. 6. Add support for cache/proxy into go-phaul code. I haven't yet finished with the prototype, but plan to do it soon, so once the above steps are done we'll be able to proceed with this one. ] Signed-off-by: Rodrigo Bruno <rbruno@gsd.inesc-id.pt> Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
- Loading branch information