Difference between revisions of "Mounting filesystems"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
m (→‎Requirement)
(Bind mounts moved to a separate article, so this is just a place holder now)
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 (the container will be an NFS Client) - see [[NFS]]
 
* 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 -- see [[Bind mounts]]
−
 
 
−
=== 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
 
−
 
 
−
----
 
−
=== 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:
 
−
 
 
−
# Mount disks after reboot.
 
−
*/5 * * * * root mount /dev/sda1 $VZROOT/root/777/mnt/sda1
 
−
 
 
−
Partition /dev/sda1 be mount after VE 777 is started.
 
  
−
[[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.

Revision as of 08:43, 31 July 2008

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 -- see Bind mounts

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.