External bind mounts - Revision history

Ptikhomirov at 09:41, 16 May 2022

2022-05-16T09:41:25Z

Ptikhomirov: /* Sharing */

2022-04-28T11:17:22Z

Sharing

Ptikhomirov: /* Sharing */

2022-04-28T11:16:38Z

Sharing

Alak: Possible false double negative

2020-06-25T13:52:12Z

Possible false double negative

Kir: don't make "Sharing" the subsection of "old days"; minor English fixes

2020-03-25T19:55:40Z

don't make "Sharing" the subsection of "old days"; minor English fixes

Ptikhomirov: External mounts, external/internal sharing/slavery.

2020-03-25T10:07:59Z

External mounts, external/internal sharing/slavery.

Kir: minor fixups

2017-06-23T21:00:08Z

minor fixups

Kir: rephrase intro

2017-06-20T17:35:24Z

rephrase intro

Kir: /* Auto detection */ fill in

2016-11-02T17:39:55Z

Auto detection: fill in

Xemul at 13:57, 25 October 2016

2016-10-25T13:57:22Z

← Older revision		Revision as of 09:41, 16 May 2022
Line 48:		Line 48:

	With this CRIU will bind mount the /foo into proper mountpoint.		With this CRIU will bind mount the /foo into proper mountpoint.
		+
		+	Note: Mounts from same superblock should remain mounts from same superblock after migration. Options `--external mnt[smth]:/smth` force criu to bindmount from the provided source, that can lead to mounts, which were from the same supperblock before dump, appear to be from different supperblock after restore, which is wrong so these option should be used carefully (can break sharing groups restore).

	== Auto detection ==		== Auto detection ==

← Older revision		Revision as of 11:17, 28 April 2022
Line 131:		Line 131:

	- External sharing is not supported (converted to internal sharing after c/r) as reasonable container environments should not allow it due to security reasons, and implementing it's lookup would lead to bad performance (host mountinfo reading).		- External sharing is not supported (converted to internal sharing after c/r) as reasonable container environments should not allow it due to security reasons, and implementing it's lookup would lead to bad performance (host mountinfo reading).
		+
	- External slavery is supported for mountpoint external mounts and the root mount. It is detected when criu can't lookup master_id of the mount across shared_ids in container mount namespaces. CRIU relies that mountpoint external source provides right shared/slave mount to copy sharing from. Everything else is considered as internal sharing/slavery.		- External slavery is supported for mountpoint external mounts and the root mount. It is detected when criu can't lookup master_id of the mount across shared_ids in container mount namespaces. CRIU relies that mountpoint external source provides right shared/slave mount to copy sharing from. Everything else is considered as internal sharing/slavery.

@@ Line 126: / Line 126: @@
   # 899 843 0:5 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
-Mounts 812 (on the host) and 861 (in a container) have the same sharing (shared group) - external sharing and mount 898 has it's own local shared group - internal sharing.
+Mounts 812 (on the host) and 861 (in a container) have the same sharing (shared group) - external sharing and mount 898 has it's own local shared group - internal sharing. Same is applicable for master_ids, if we convert them into slaves external/internal shared_id would convert to external/internal master_id.
-Before [https://github.com/checkpoint-restore/criu/pull/906 #906] we were detecting this external/internal sharing state for auto-detected external mounts only, but we need it for manual external mounts too. Moreover, this also applies to manual external slave mounts they can be external/internal slaves too.
+[https://criu.org/Mount-v2 Mount-v2] is introducing a better support of external sharing:
-So we detect that the mount is from external sharing if in mount namespace of CRIU there are mounts of the same shared group and also we detect that the mount is from external slavery if there is no master mount for it in CT mount namespaces.
+- External sharing is not supported (converted to internal sharing after c/r) as reasonable container environments should not allow it due to security reasons, and implementing it's lookup would lead to bad performance (host mountinfo reading).
 == Old days ==

@@ Line 62: / Line 62: @@
 : Also enable dumping of external shared mounts (as in <code>mount --make-shared</code>)
-By default, neither master nor shared external mounts are not dumped (if found, dump is aborted). Note if <code>''flags''</code> are not given, semicolon is optional.
+By default, neither master nor shared external mounts are dumped (if found, dump is aborted). Note if <code>''flags''</code> are not given, semicolon is optional.
 === Examples ===

@@ Line 68: / Line 68: @@
   criu dump ... --external 'mnt[]'
-Auto detect and dump all external bind mounts.
+Auto-detect and dump all external bind mounts.
   criu dump ... --external 'mnt[]:s'
-Auto detect and dump all external bind mounts, including the shared ones.
+Auto-detect and dump all external bind mounts, including the shared ones.
   criu dump ... --external 'mnt[]:sm'
-Auto detect and dump all external bind mounts, including the shared and the master ones.
+Auto-detect and dump all external bind mounts, including the shared and the master ones.
-== Old days ==
+== Sharing ==
 External bindmounts can both have internal/external sharing. Please see the example:
@@ Line 133: / Line 126: @@
   # 899 843 0:5 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
-Mounts 812 (on host) and 861 (in container) have the same sharing (shared group) - external sharing and mount 898 has it's own local shared group - internal sharing.
+Mounts 812 (on the host) and 861 (in a container) have the same sharing (shared group) - external sharing and mount 898 has it's own local shared group - internal sharing.
-Before [https://github.com/checkpoint-restore/criu/pull/906 #906] we were detecting this external/internal sharing state for auto detected external mounts only, but we need it for manual external mounts too. Moreover this also applies to manual external slave mounts they can be external/internal slaves too.
+== Old days ==
-So we detect that the mount is from external sharing if in mount namespace of CRIU there are mounts of same shared group and also we detect that the mount is from external slavery if there is no master mount for it in CT mount namespaces.
+For now the same behavior is configured with the <code>--ext-mount-map KEY:VAL</code> option. Soon this option will be [[deprecation|deprecated]].

← Older revision		Revision as of 10:07, 25 March 2020
Line 84:		Line 84:
	[[Category:HOWTO]]		[[Category:HOWTO]]
	[[Category:External]]		[[Category:External]]
		+
		+	=== Sharing for external bindmounts ===
		+
		+	External bindmounts can both have internal/external sharing. Please see the example:
		+
		+	# Preparation
		+	unshare -m --propagation private
		+	mkdir /external_mount_sharing_test
		+	mount -t tmpfs tmpfs /external_mount_sharing_test/
		+	mount --make-private /external_mount_sharing_test/
		+	cd /external_mount_sharing_test
		+	# Source of external mount
		+	mkdir external_mount
		+	mount -t tmpfs tmpfs-external external_mount/
		+	mount --make-shared external_mount/
		+	cat /proc/$$/mountinfo \| grep external
		+	# 811 755 0:60 / /external_mount_sharing_test rw,relatime - tmpfs tmpfs rw
		+	# 812 811 0:62 / /external_mount_sharing_test/external_mount rw,relatime shared:290 - tmpfs tmpfs-external rw
		+
		+	# Switch to CT mntns
		+	unshare -m --propagation unchanged sh
		+	mkdir root
		+	mount -t tmpfs tmpfs-root root/
		+	mkdir root/external_sharing root/internal_sharing root/proc
		+
		+	# Create external mount
		+	mount --bind external_mount/ root/external_sharing
		+	mount --bind external_mount/ root/internal_sharing
		+	mount --make-private root/internal_sharing
		+	mount --make-shared root/internal_sharing
		+
		+	# More preparations
		+	mount --bind /proc root/proc
		+	cd root
		+	mkdir bin lib64
		+	SH=$(which sh)
		+	cp $SH bin
		+	cp $(ldd $SH \| grep "/lib64" \| sed 's/^.\(\/lib64\S\)\s.*$/\1/') lib64
		+	CAT=$(which cat)
		+	cp $CAT bin
		+	cp $(ldd $CAT \| grep "/lib64" \| sed 's/^.\(\/lib64\S\)\s.*$/\1/') lib64
		+	PATH=$PATH:/bin
		+	chroot . sh
		+	cat /proc/$$/mountinfo
		+	# 843 841 0:63 / / rw,relatime - tmpfs tmpfs-root rw
		+	# 861 843 0:62 / /external_sharing rw,relatime shared:290 - tmpfs tmpfs-external rw
		+	# 898 843 0:62 / /internal_sharing rw,relatime shared:349 - tmpfs tmpfs-external rw
		+	# 899 843 0:5 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
		+
		+	Mounts 812 (on host) and 861 (in container) have the same sharing (shared group) - external sharing and mount 898 has it's own local shared group - internal sharing.
		+
		+	Before [https://github.com/checkpoint-restore/criu/pull/906 #906] we were detecting this external/internal sharing state for auto detected external mounts only, but we need it for manual external mounts too. Moreover this also applies to manual external slave mounts they can be external/internal slaves too.
		+
		+	So we detect that the mount is from external sharing if in mount namespace of CRIU there are mounts of same shared group and also we detect that the mount is from external slavery if there is no master mount for it in CT mount namespaces.

@@ Line 22: / Line 22: @@
 == How to teach CRIU to dump them ==
-By default CRIU doesn't dump such mountpoints, because there's no way CRIU will be able to restore it -- the root of these mounts is out of the scope of what CRIU dumped. In the logs you would see the message like
+By default CRIU doesn't dump such mountpoints, because there's no way CRIU will be able to restore it -- the root of these mounts is out of scope of what CRIU dumped. In the logs you would see a message like
 :/bar doesn't have a proper root mount
-which will mean, that the mountpoint /bar has inaccessible root.
+which means the mountpoint /bar has inaccessible root.
 To dump and restore them there's the <code>--external mnt[KEY]:VAL</code> option that sets up external mounts root mapping.
-On dump, KEY is a mountpoint inside container and correspoding VAL is a string that will be written into the image as mountpoint's root value.
+On dump, KEY is a mountpoint inside container, and corresponding VAL is a string that will be written into the image as mountpoint's root value.
-On restore KEY is the value from the image (VAL from dump) and the VAL is the path on host that will be bind-mounted into container (to the mountpoint path from image).
+On restore, KEY is the value from the image (VAL from dump), and the VAL is the path on host that will be bind-mounted into container (to the mountpoint path from image).
 For example, if we want to dump the task above we should call

@@ Line 1: / Line 1: @@
 __TOC__
-Typical external resource when dumping a container (especially LXC/Docker) -- is a mount point whose root sits outside of the container's root. This situation was intended to be resolved using [[plugins]] but turned out to be ''so'' frequent, that we introduced a non-plugin way of handling them.
+One of typical external resources when dumping a container (especially LXC/Docker) is a mount point whose root sits outside of the container's root. This situation was intended to be resolved using [[plugins]] but turned out to be common enough to introduce a built-in way of handling it.
 == What is external bind mount ==

@@ Line 51: / Line 51: @@
 == Auto detection ==
-FIXME
+In case one wants CRIU to autodetect and dump all the external bind mounts, and there is no need to change host mount points on restore, one can use a special syntax:
 == Old days ==

@@ Line 28: / Line 28: @@
 which will mean, that the mountpoint /bar has inaccessible root.
-To dump and restore them there's the <code>--ext-mount-map KEY:VAL</code> option that sets up external mounts root mapping.
+To dump and restore them there's the <code>--external mnt[KEY]:VAL</code> option that sets up external mounts root mapping.
 On dump, KEY is a mountpoint inside container and correspoding VAL is a string that will be written into the image as mountpoint's root value.
@@ Line 36: / Line 36: @@
 For example, if we want to dump the task above we should call
-  criu dump ... --ext-mount-map /bar:barmount
+  criu dump ... --external mnt[/bar]:barmount
 The word <code>barmount</code> is an arbitrary identifier, that will be put in the image file instead of the original root path
@@ Line 45: / Line 45: @@
 On restore we should tell CRIU where to bind mount the <code>barmount</code> from like this
-  criu restore ... --ext-mount-map barmount:/foo
+  criu restore ... --external mnt[barmount]:/foo
 With this CRIU will bind mount the /foo into proper mountpoint.
@@ Line 52: / Line 52: @@
 FIXME
 [[Category:HOWTO]]
 [[Category:External]]