Using BIND Mounts to Create A Simplified BaseVol/GuestVol Linux Server

Prev

http://linuxvm.org/present/misc/basevol.html

last updated on 28 January 2004 by William Scully, Senior Systems Programmer, Computer Associates.

This is a simpler procedure to follow to create a base-volume/guest-volume Linux for zSeries server which exploits the bind command. The procedure here was developed on a SUSE SLES7 2.4 kernel and the specific implementation here has been tested with the SUSE SLES8 2.4 kernel.

Overview

The plan is to create a two-pack system for each Linux system.

The first pack is the so-called base volume, or basevol. Among these materials are those which are rarely changed and can be shared read-only among several servers simultaneously. This device is owned by the so-called base-server, or, in the examples below, userid LINXBASE.
The second volume is the so-called guest volume or guestvol. These are the materials, which are unique to each Linux server and in directories which must be read/write. The userid used in the examples below is LNXGUEST.

The goal is to place as many programs (both the kernel code and vendor-supplied packages) as possible in the base volume so that it is leveraged over and over again. The remaining guest volume read/write disk space given to a typical Linux server can be far smaller as a result. Also, because fixes applied to packages installed onto the read-only disk are used by all servers, the maintenance burden is substantially decreased.

To implement this scheme requires only a modest change in the way a Linux server is created. Overall, the approach is to prevent the operating system from mounting the base volume materials in read/write mode during the boot process. This is easily accomplished because:

When the Linux boot process starts all directories are in read-only mode.
As the boot process continues, vendor-supplied scripts remount Linux directories in read/write mode, as needed.

It is easy to change the vendor-supplied boot-time scripts to avoid the read/write mounting of the Linux materials. It is also easy to create new boot scripts which mount in read/write mode only those directories which must be read/write. Thus we can easily pick and choose which directories (and subdirectories) are read-only and which are read/write. It is the use of bind-type mount commands which allow specific (sub-)directories to be R/O or R/W. The Redbook reference above includes a useful description of how bind mounts work. In particular you may want to read Sections 8.1 through 8.8.

Note that an objective is to hide, as much as possible, the fact that the server is using bind mounts. Using this implementation users who issue mount -l or cat /etc/mtab will see the same results as if the R/O server was booted with R/W directories. Only if the user issues a cat /proc/mounts will they see the details of what directories are mounted using the bind option.

Using BIND Mounts to Create A Simplified BaseVol/GuestVol Linux Server

Overview

Read-only and Read/Write Directories