Mounting filesystems - Revision history

Kir: new content moved to Bind mounts -- Undo revision 7333 by Chronos (Talk)

2009-05-28T10:36:43Z

new content moved to Bind mounts -- Undo revision 7333 by Chronos (Talk)

Chronos: Info about mount on start

2009-05-28T06:16:07Z

Info about mount on start

Kir: simplify

2009-01-26T12:05:52Z

simplify

Kir: Bind mounts moved to a separate article, so this is just a place holder now

2008-07-31T08:43:11Z

Bind mounts moved to a separate article, so this is just a place holder now

Bsv999: /* Requirement */

2008-07-30T14:25:36Z

‎Requirement

Bsv999: /* Requirement */

2008-07-30T14:24:09Z

‎Requirement

Botinki Kira: Robot: Automated text replacement (-VE +container)

2008-03-11T11:01:35Z

Robot: Automated text replacement (-VE +container)

Botinki Kira: Robot: Automated text replacement (-VEs +containers)

2008-03-11T09:47:31Z

Robot: Automated text replacement (-VEs +containers)

Kir: /* Bind mount from Hardware Node */ use $VZROOT everywhere

2007-12-27T10:50:57Z

‎Bind mount from Hardware Node: use $VZROOT everywhere

Kir: /* Requirement */ use $VZROOT

2007-12-27T10:49:46Z

‎Requirement: use $VZROOT

← Older revision		Revision as of 10:36, 28 May 2009
Line 5:		Line 5:
	* [[Bind mounts]] from Hardware Node		* [[Bind mounts]] from Hardware Node

−	Also, you can grant a container an access a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out.	+	Also, you can grant a container an access a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out.
−
−	~~=Mount filesystem on VE start=~~
−
−	You need to create mount script in openvz configuration directory (/etc/vz/conf) with name <veid>.mount. If you need to mount filesystem to all containers than name of script should be vps.mount and inside script ${VEID} variable can be used.
−
−	~~Example:~~
−	~~<pre>#!/bin/bash~~
−	~~mount --bind /mnt/disk /vz/root/${VEID}/mnt/disk~~
−	~~exit ${?}</pre>~~
−
−	~~For unmounting filesystem file vps.umount can be used.~~
−
−	~~Example:~~
−	~~<pre>#!/bin/bash~~
−	~~umount /vz/root/${VEID}/mnt/disk~~
−	~~exit 0</pre>~~
−
−	~~''Notice:''~~
−	~~<veid>.umount scripts are not very necessary: everything will be umounted automatically on VE stop. But you should than mount with -n option in mount script~~.

← Older revision		Revision as of 06:16, 28 May 2009
Line 5:		Line 5:
	* [[Bind mounts]] from Hardware Node		* [[Bind mounts]] from Hardware Node

−	Also, you can grant a container an access a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out.	+	Also, you can grant a container an access a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out.
		+
		+	=Mount filesystem on VE start=
		+
		+	You need to create mount script in openvz configuration directory (/etc/vz/conf) with name <veid>.mount. If you need to mount filesystem to all containers than name of script should be vps.mount and inside script ${VEID} variable can be used.
		+
		+	Example:
		+	<pre>#!/bin/bash
		+	mount --bind /mnt/disk /vz/root/${VEID}/mnt/disk
		+	exit ${?}</pre>
		+
		+	For unmounting filesystem file vps.umount can be used.
		+
		+	Example:
		+	<pre>#!/bin/bash
		+	umount /vz/root/${VEID}/mnt/disk
		+	exit 0</pre>
		+
		+	''Notice:''
		+	<veid>.umount scripts are not very necessary: everything will be umounted automatically on VE stop. But you should than mount with -n option in mount script.

@@ Line 1: / Line 1: @@
 To mount a file system inside a container, you have several choices:
-* NFS (the container will be an NFS Client) - see [[NFS]]
+* [[NFS]], when container as an NFS client
-* FUSE - see [[FUSE]]
+* [[FUSE]] (filesystem in userspace)
-* Bind mount from Hardware Node -- see [[Bind mounts]]
+* [[Bind mounts]] from Hardware Node
 Also, you can grant a container an access  a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out.

@@ Line 1: / Line 1: @@
-== Mounting filesystems within a container ==
+To mount a file system inside a container, you have several choices:
 * NFS (the container will be an NFS Client) - see [[NFS]]
 * FUSE - see [[FUSE]]
-* Bind mount from Hardware Node
+* Bind mount from Hardware Node -- see [[Bind mounts]]
-[[Category:HOWTO]]
+Also, you can grant a container an access  a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out.

@@ Line 48: / Line 48: @@
 ----
-Attention:
+=== Attention ===
 Partition with <b>reiserfs</b> file system don't mounted in container now (may be later). You can mount reiserfs on the HN added two rows in /etc/vz/cron:

@@ Line 46: / Line 46: @@
   tmpfs                   484712         0    484712   0% /dev/shm
   ext3                 117662052 104510764   7174408  94% /home
 [[Category:HOWTO]]

@@ Line 1: / Line 1: @@
-== Mounting filesystems within a VE ==
+== Mounting filesystems within a container ==
-To mount filesystems inside a VE, you have several choices:
+To mount filesystems inside a container, you have several choices:
-* NFS (the VE will be an NFS Client) - see [[NFS]]
+* NFS (the container will be an NFS Client) - see [[NFS]]
 * FUSE - see [[FUSE]]
 * Bind mount from Hardware Node
@@ Line 11: / Line 11: @@
 Recent Linux kernels support an operation called 'bind mounting' which makes part of a mounted filesystem visible at some other mount point. See 'man bind' for more information.
-Bind mounts can be used to make directories on the hardware node visible to the VE.
+Bind mounts can be used to make directories on the hardware node visible to the container.
-OpenVZ uses two directories. Assuming our VE is numbered 777, these directories are:
+OpenVZ uses two directories. Assuming our container is numbered 777, these directories are:
   $VZROOT/private/777
@@ Line 24: / Line 24: @@
    $VZROOT/private -> /mnt/openvz
-Putting VE root directories onto a separate file system (not the hardware node root file system) is good storage management practice. It protects the Hardware Node root file system from being filled up by a VE; this could cause problems on the Hardware Node.
+Putting container root directories onto a separate file system (not the hardware node root file system) is good storage management practice. It protects the Hardware Node root file system from being filled up by a container; this could cause problems on the Hardware Node.
 === Requirement ===
@@ Line 30: / Line 30: @@
 '''On the HN we have a directory <code>/home</code> which we wish to make available (shared) to all containers.'''
-You would think that you could bind mount this directory, as in: <code>mount --bind /home $VZROOT/private/777/home</code> but this does not work — the contents of <code>/home</code> cannot be seen within the VE.
+You would think that you could bind mount this directory, as in: <code>mount --bind /home $VZROOT/private/777/home</code> but this does not work — the contents of <code>/home</code> cannot be seen within the container.
-This is where the second directory listed above (<code>$VZROOT/root/777</code>) is used. If a VE is not started, this directory is empty. But after starting a VE, this directory contains what the VE sees as its mounted file systems.
+This is where the second directory listed above (<code>$VZROOT/root/777</code>) is used. If a container is not started, this directory is empty. But after starting a container, this directory contains what the container sees as its mounted file systems.
 The correct command to issue on the HN is:
@@ Line 38: / Line 38: @@
    mount --bind /home $VZROOT/root/777/home
-The VE must be started and the destination directory must exist. The VE will see this directory mounted like this:
+The container must be started and the destination directory must exist. The container will see this directory mounted like this:
   # df

@@ Line 18: / Line 18: @@
   $VZROOT/root/777
-{{Note|<code>$VZROOT</code> is usually <code>/vz</code>, on Debian systems however this is <code>/var/lib/vz</code>. In this document this is further referred to as <code>/vz</code>.}}
+{{Note|<code>$VZROOT</code> is usually <code>/vz</code>, on Debian systems however this is <code>/var/lib/vz</code>. In this document this is further referred to as <code>$VZROOT</code> -- substitute it with what you have.}}
-The /vz/private directory contains root directory contents. This directory or subdirectory may be symlinked onto a different filesystem, for example:
+The $VZROOT/private directory contains root directory contents. This directory or subdirectory may be symlinked onto a different file system, for example:
-   /vz/private -> /mnt/openvz
+   $VZROOT/private -> /mnt/openvz
-Putting VE root directories onto a separate filesystem (not the hardware node root filesystem) is good storage management practice. It protects the Hardware Node root filesystem from being filled up by a VE; this could cause problems on the Hardware Node.
+Putting VE root directories onto a separate file system (not the hardware node root file system) is good storage management practice. It protects the Hardware Node root file system from being filled up by a VE; this could cause problems on the Hardware Node.
 === Requirement ===