Live migration - Revision history

Prajwal S N: Add kill command

2023-01-12T18:08:16Z

Add kill command

Radostin: /* Restore */ Using -t with criu restore is obsoleted

2019-01-13T12:39:46Z

Restore: Using -t with criu restore is obsoleted

Radostin at 18:20, 25 November 2018

2018-11-25T18:20:02Z

Radostin: Fix typo

2017-11-13T19:56:43Z

Fix typo

Xemul: /* Migration sequence */

2017-03-29T06:33:06Z

Migration sequence

Xemul: /* See also */

2016-09-21T09:42:02Z

Kir: add and populated 'see also'

2016-08-31T04:19:15Z

add and populated 'see also'

Xemul at 18:26, 20 February 2015

2015-02-20T18:26:07Z

Xemul: Added note about shell job

2015-02-19T20:45:56Z

Added note about shell job

Xemul at 11:07, 14 February 2014

2014-02-14T11:07:29Z

@@ Line 35: / Line 35: @@
 If everything went OK you can return on the source node and kill stopped tasks on it.
-  [src]# FIXME put command here
+  [src]# kill <pid>
 == Notes ==

@@ Line 30: / Line 30: @@
 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 ===

← Older revision		Revision as of 18:20, 25 November 2018
Line 1:		Line 1:
	{{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.}}
		+
		+	Live migration attempts to provide a seamless transfer of service between physical machines without impacting client processes or applications.

	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.

@@ Line 7: / Line 7: @@
 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.

@@ Line 3: / Line 3: @@
 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.
-== Migration sequence ==
+== Prerequisites ==
 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 tasks you should do these steps:
+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.
 === Dump ===

@@ Line 44: / Line 44: @@
 * [[Iterative migration]]
 * [[Disk-less migration]]
 * [[Page server]]
 [[Category: HOWTO]]
 [[Category: Live migration]]

← Older revision		Revision as of 18:26, 20 February 2015
Line 40:		Line 40:

	[[Category: HOWTO]]		[[Category: HOWTO]]
		+	[[Category: Live migration]]

@@ Line 33: / Line 33: @@
 == Notes ==
-The directories with images would contain two copies of applications memory, which may be space-consuming. The CRIU can perform [[disk-less migration]] to address this.
+* The directories with images would contain two copies of applications memory, which may be space-consuming. The CRIU can perform [[disk-less migration]] to address this.
-Another issue with this way of doing live migration is that while copying memory on remote host tasks remain frozen. If there's a LOT of memory, this freeze time can be big. CRIU can speed this up by doing [[iterative migration]].
+* Another issue with this way of doing live migration is that while copying memory on remote host tasks remain frozen. If there's a LOT of memory, this freeze time can be big. CRIU can speed this up by doing [[iterative migration]].
 [[Category: HOWTO]]

← Older revision		Revision as of 11:07, 14 February 2014
Line 1:		Line 1:
		+	{{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.
−
−	~~{{Note\|The main article about live-migration of containers is [[P.Haul\|here]]}}~~

	== Migration sequence ==		== Migration sequence ==