Changes

{{Note|The main article about live-migration is [[P.Haul|here]]. The article below is just description of how it can be done.}}

{{Note|The main article about live-migration is [[P.Haul|here]]. The article below is just description of how it can be done.}}

The <code>criu</code> utility can be used to perform live migration of apps or containers. This page is a sort of HOWTO describing this.

The <code>criu</code> utility can be used to perform live migration of apps or containers. This page is a sort of HOWTO describing this.

In order to live-migrate an application or a container you should make sure, that files, that are/can be accessed by processes you're migrating are available on both nodes -- source and destination. This can be achieved by using either shared file-system such as NFS, GlusterFS or CEPH, or by using <code>rsync</code> to copy files from one box to another. Further in this article we assume, that the file-system is the same on both sides.

In order to live-migrate an application or a container you should make sure, that files, that are/can be accessed by processes you're migrating are available on both nodes -- source and destination. This can be achieved by using either shared file-system such as NFS, GlusterFS or CEPH, or by using <code>rsync</code> to copy files from one box to another. Further in this article we assume, that the file-system is the same on both sides.

Another thing you should take care of is the networking. General rule here is that IP addresses, that you application uses should be available on the destination host. The reason for that is -- when restoring TCP sockets CRIU will try to bind() and connect() them back using their original credentials, and if the requested IP address is not available for some reason on the destination side, the respective system call will fail. Also during migration the connections will be locked by CRIU and there are two options here.

Another thing you should take care of is the networking. General rule here is that IP addresses, that your application uses should be available on the destination host. The reason for that is -- when restoring TCP sockets CRIU will try to bind() and connect() them back using their original credentials, and if the requested IP address is not available for some reason on the destination side, the respective system call will fail. Also during migration the connections will be locked by CRIU and there are two options here.

First, is when your app shares the networking with the host. In this case CRIU locks connections using iptables rules, so you should make sure the rules are available on the destination side. Second option is when the app lives in a net namespace (a container). In this case CRIU will call [[action scripts]] to lock the network and it's up to you how to lock it. In case of [[Docker]] the latter daemon handles it by the libnetwork library.

First, is when your app shares the networking with the host. In this case CRIU locks connections using iptables rules, so you should make sure the rules are available on the destination side. Second option is when the app lives in a net namespace (a container). In this case CRIU will call [[action scripts]] to lock the network and it's up to you how to lock it. In case of [[Docker]] the latter daemon handles it by the libnetwork library.

Go to the destination node and restore the apps from images on it:

Go to the destination node and restore the apps from images on it:

  [dst]# criu restore --tree <pid> --images-dir <path-to-images>

  [dst]# criu restore --images-dir <path-to-images>

=== Kill ===

=== Kill ===