Disk-less migration - Revision history

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

2019-01-13T12:36:07Z

criu restore: Using -t with criu restore is obsoleted

Xemul: /* See also */

2016-09-21T09:41:44Z

Rppt at 05:13, 30 August 2016

2016-08-30T05:13:10Z

Kir: a few minor fixes

2016-08-30T00:11:48Z

a few minor fixes

Kir: /* See also */ filled in

2016-08-29T23:51:05Z

Kir: Do not abuse "definition list" for something that should be handled by subsections. English, cleanups, fixes etc.

2016-08-29T23:50:13Z

Do not abuse "definition list" for something that should be handled by subsections. English, cleanups, fixes etc.

Rppt at 14:05, 24 March 2016

2016-03-24T14:05:49Z

Xemul at 18:27, 20 February 2015

2015-02-20T18:27:13Z

Xemul at 17:59, 28 January 2015

2015-01-28T17:59:12Z

Efiop: fix typo

2014-07-08T13:53:58Z

fix typo

@@ Line 31: / Line 31: @@
 Restore the applications. By now, the page server should have been stopped (check this by its return code), and images with pages are already in the <code><dir></code>.
-  dst# criu restore --tree <pid> --images-dir <dir>
+  dst# criu restore --images-dir <dir>
 === Cleanup tmpfs ===

@@ Line 47: / Line 47: @@
 * [[Live migration]]
 * [[Iterative migration]]
 * [[Page server]]

@@ Line 1: / Line 1: @@
-When performing [[live migration]], CRIU puts image files with applications' memory on a storage user provides. If the images with applications' memory are too big, this will result in big delays, due to the need to copy this data several times. Other than this, in some situations it would be desirable to avoid using the storage at all not to increase the load on it. This article describes how one can do [[live migration]] without putting images on disk, step by steps.
+When performing [[live migration]], CRIU puts image files with applications' memory on a storage user provides. If the images with applications' memory are too big, this will result in big delays, due to the need to copy this data several times. Other than this, in some situations it would be desirable to avoid using the storage at all not to increase the load on it. This article describes how one can do [[live migration]] without putting images on disk, step by step.
 == The process ==
@@ Line 14: / Line 14: @@
   dst# criu page-server --images-dir <dir> --port <port>
-Now, page server will wait for incoming connections to write the applications memory to the <code><dir></code>. When doing [[iterative migration]], you can make page server to automatically drop duplicated pages by using <code>--auto-dedup</code> option. See the [[incremental dumps]] article for details.
+Now, page server will wait for incoming connections to write the applications' memory to the <code><dir></code>. When doing [[iterative migration]], you can make page server to automatically drop duplicated pages by using <code>--auto-dedup</code> option. See the [[incremental dumps]] article for details.
 === criu dump ===

@@ Line 4: / Line 4: @@
 === Preparation ===
 Prepare a tmpfs mount on both sides, where you will put images other than those with apps memory. These images are typically very small and will not create significant memory pressure on nodes.
@@ Line 18: / Line 17: @@
 === criu dump ===
 Dump the applications, just like it would have been done when doing live migration, but with options explaining to criu where the page server is:
@@ Line 36: / Line 34: @@
 === Cleanup tmpfs ===
-: Kill the tmpfs mount with old images. It's no longer required.
+Kill the tmpfs mount with old images. It's no longer required.
   dst# umount <dir>
 === Kill processes on source ===
-Kill apps on the source node, as they are already running on the destination.
+ src# FIXME
 == See also ==

@@ Line 45: / Line 45: @@
 == See also ==
 [[Category: HOWTO]]
 [[Category: Memory]]
 [[Category: Live migration]]

@@ Line 1: / Line 1: @@
-When performing a [[live migration]] <code>criu</code> will put image files with applications' memory on a storage user provides. If the images with applications' memory are too big, this will result in big delays, due to the need to copy this data several times. Other than this, in some situations it would be desirable to avoid using the storage at all not to increase the load on it. This article describes how one can do [[live migration]] without putting images on disk.
+When performing [[live migration]], CRIU puts image files with applications' memory on a storage user provides. If the images with applications' memory are too big, this will result in big delays, due to the need to copy this data several times. Other than this, in some situations it would be desirable to avoid using the storage at all not to increase the load on it. This article describes how one can do [[live migration]] without putting images on disk, step by steps.
-; step 1
+== The process ==
-: Prepare a tmpfs mount on both sides, where you will put images other than those with apps memory. These images are typically very small and will not create significant memory pressure on nodes.
   dst# mount -t tmpfs none <dir>
   src# mount -t tmpfs none <dir>
-; step 2
+=== Run page server ===
-: Launch a page server on the destination node. The page server will accept pages from <code>criu</code> and will put them into the tmpfs mount. Since we're about to run the apps on the destination node, it will ''have'' to bear with this memory consumption. The source node will not have to store these images.
+Launch a page server on the destination node. The page server will accept pages from <code>criu</code> and will put them into the tmpfs mount. Since we're about to run the apps on the destination node, it will ''have'' to bear with this memory consumption. The source node will not have to store these images.
   dst# criu page-server --images-dir <dir> --port <port>
-After this criu will wait for incoming connections to read the apps memory and put them into <code><dir></code>. Note, that if you're going to run through several iterations (see [[iterative migration]] you can make page-server to automatically drop pages, that get re-sent to it with the <code>--auto-dedup</code> option. See the [[incremental dumps]] article for details.
+Now, page server will wait for incoming connections to write the applications memory to the <code><dir></code>. When doing [[iterative migration]], you can make page server to automatically drop duplicated pages by using <code>--auto-dedup</code> option. See the [[incremental dumps]] article for details.
-; step 3
+=== criu dump ===
-: Dump the applications, just like it would have been done when doing live migration, but with options explaining to criu where the page server is
   src# criu dump --tree <pid> --images-dir <dir> --leave-stopped --page-server --address <dst> --port <port>
-; step 4
+=== Copy images ===
-: Copy rest images onto destination node
+Copy the rest of images onto the destination node:
   src# scp -r <dir> <dst-node>/<dir>
-As was said, CRIU images other than those with pages are very small and this won't take long.
+As mentioned before, CRIU images being copied here (everything but the process' memory) are relatively small so it would not take long.
-; step 5
+=== criu restore ===
-: Restore the applications. By that time page server should have been stopped (check this by it's ret code) and images with pages are already in the <code><dir></code>.
+Restore the applications. By now, the page server should have been stopped (check this by its return code), and images with pages are already in the <code><dir></code>.
   dst# criu restore --tree <pid> --images-dir <dir>
-; step 6
+=== Cleanup tmpfs ===
-: Kill the tmpfs mount with old images. It's no longer required
+: Kill the tmpfs mount with old images. It's no longer required.
   dst# umount <dir>
-; step 7
+=== Kill processes on source ===
-: Kill apps on the source node, as they are already on the destination one
 [[Category: HOWTO]]
 [[Category: Memory]]
 [[Category: Live migration]]

← Older revision		Revision as of 18:27, 20 February 2015
Line 41:		Line 41:
	[[Category: HOWTO]]		[[Category: HOWTO]]
	[[Category: Memory]]		[[Category: Memory]]
		+	[[Category: Live migration]]

← Older revision		Revision as of 17:59, 28 January 2015
Line 40:		Line 40:

	[[Category: HOWTO]]		[[Category: HOWTO]]
		+	[[Category: Memory]]

@@ Line 8: / Line 8: @@
 ; step 2
-: Launch a page server on destination node. The page server will accept pages from <code>criu</code> and will put them into the tmpfs mount. Since we're about to rucn the apps on destination node, it will ''have'' to bear with this memory consumption. The source node will not have to store these images.
+: Launch a page server on destination node. The page server will accept pages from <code>criu</code> and will put them into the tmpfs mount. Since we're about to run the apps on destination node, it will ''have'' to bear with this memory consumption. The source node will not have to store these images.
   dst# criu page-server --images-dir <dir> --port <port>