|
|
| (5 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | == Mounting filesystems within a container ==
| + | To mount a file system inside a container, you have several choices: |
| | | | |
| − | To mount filesystems inside a container, you have several choices:
| + | * [[NFS]], when container as an NFS client |
| | + | * [[FUSE]] (filesystem in userspace) |
| | + | * [[Bind mounts]] from Hardware Node |
| | | | |
| − | * NFS (the container will be an NFS Client) - see [[NFS]]
| + | 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. |
| − | * FUSE - see [[FUSE]]
| |
| − | * Bind mount from Hardware Node
| |
| − | | |
| − | === 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|<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 $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 <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 container.
| |
| − | | |
| − | 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:
| |
| − | | |
| − | 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
| |
| − | | |
| − | [[Category:HOWTO]]
| |
