Difference between revisions of "Mounting filesystems"
Botinki Kira (talk | contribs) m (Robot: Automated text replacement (-VEs +containers)) |
Botinki Kira (talk | contribs) m (Robot: Automated text replacement (-VE +container)) |
||
| Line 1: | Line 1: | ||
| − | == Mounting filesystems within a | + | == Mounting filesystems within a container == |
| − | To mount filesystems inside a | + | To mount filesystems inside a container, you have several choices: |
| − | * NFS (the | + | * NFS (the container will be an NFS Client) - see [[NFS]] |
* FUSE - see [[FUSE]] | * FUSE - see [[FUSE]] | ||
* Bind mount from Hardware Node | * 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. | 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 | + | Bind mounts can be used to make directories on the hardware node visible to the container. |
| − | OpenVZ uses two directories. Assuming our | + | OpenVZ uses two directories. Assuming our container is numbered 777, these directories are: |
$VZROOT/private/777 | $VZROOT/private/777 | ||
| Line 24: | Line 24: | ||
$VZROOT/private -> /mnt/openvz | $VZROOT/private -> /mnt/openvz | ||
| − | Putting | + | 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 === | === 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.''' | '''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 | + | 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 | + | 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: | The correct command to issue on the HN is: | ||
| Line 38: | Line 38: | ||
mount --bind /home $VZROOT/root/777/home | mount --bind /home $VZROOT/root/777/home | ||
| − | The | + | The container must be started and the destination directory must exist. The container will see this directory mounted like this: |
# df | # df | ||
Revision as of 11:01, 11 March 2008
Mounting filesystems within a container
To mount filesystems inside a container, you have several choices:
Bind mount from Hardware Node
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 container.
OpenVZ uses two directories. Assuming our container is numbered 777, these directories are:
$VZROOT/private/777 $VZROOT/root/777
|
Note: $VZROOT is usually /vz, on Debian systems however this is /var/lib/vz. In this document this is further referred to as $VZROOT -- substitute it with what you have.
|
The $VZROOT/private directory contains root directory contents. This directory or subdirectory may be symlinked onto a different file system, for example:
$VZROOT/private -> /mnt/openvz
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
On the HN we have a directory /home which we wish to make available (shared) to all containers.
You would think that you could bind mount this directory, as in: mount --bind /home $VZROOT/private/777/home but this does not work — the contents of /home cannot be seen within the container.
This is where the second directory listed above ($VZROOT/root/777) 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:
mount --bind /home $VZROOT/root/777/home
The container must be started and the destination directory must exist. The container will see this directory mounted like this:
# df Filesystem 1K-blocks Used Available Use% Mounted on simfs 10485760 298728 10187032 3% / tmpfs 484712 0 484712 0% /lib/init/rw tmpfs 484712 0 484712 0% /dev/shm ext3 117662052 104510764 7174408 94% /home
