Difference between revisions of "Mounting filesystems"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
($VZROOT, formatting)
(new content moved to Bind mounts -- Undo revision 7333 by Chronos (Talk))
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Mounting filesystems within a VE ==
+
To mount a file system inside a container, you have several choices:
  
To mount filesystems inside a VE, you have several choices:
+
* [[NFS]], when container as an NFS client
 +
* [[FUSE]] (filesystem in userspace)
 +
* [[Bind mounts]] from Hardware Node
  
* NFS (the VE 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 VE.
 
 
 
OpenVZ uses two directories. Assuming our VE 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>/vz</code>.}}
 
 
 
The /vz/private directory contains root directory contents. This directory or subdirectory may be symlinked onto a different filesystem, for example:
 
 
 
  /vz/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.
 
 
 
=== Requirement ===
 
 
 
'''On the HN we have a directory '/home' which we wish to make available (shared) to all VEs.'''
 
 
 
You would think that you could bind mount this directory, as in: 'mount --bind /home /vz/private/777/home' but this does not work — the contents of /home cannot be seen within the VE.
 
 
 
This is where the second directory listed above (/vz/root/777) 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 filesystems.
 
 
 
The correct command to issue on the HN is:
 
 
 
  mount --bind /home /var/lib/vz/root/777/home
 
 
 
The VE must be started and the destination directory must exist. The VE 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]]
 

Latest revision as of 10:36, 28 May 2009

To mount a file system inside a container, you have several choices:

  • NFS, when container as an NFS client
  • FUSE (filesystem in userspace)
  • 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.