There might be situations when you need to do additional actions when a particular VPS is
started or stopped. For example, if you want to be able to access the Host OS file system (or part
of it) from VPS 101, then you can bind mount it inside the VPS manually from the Host OS.
However, after you restart the VPS, your mount disappears, and you should manually type the
mount command again.
OpenVZ allows you to automate procedures like the above by using OpenVZ action scripts.
There are six action scripts defined in this version of OpenVZ:
global
mount
- This script runs immediately after vzctl mounts the VPS private area. The VPS itself is
not yet running and the script is running in the Host OS context.
- This script runs immediately after the global mount script. The VPS is still not running, and
the scripts is called in the Host OS context.
- After vzctl has started a VPS, it runs the VPS start script. The script is running already
in the VPS context.
- This script runs before the VPS is stopped, in the VPS context.
- After the VPS has been already stopped, the umount script is executed, and the script runs
in the Host OS context.
umount
- This script runs when vzctl is about to dismount the VPS private area. It also runs in the
Host OS context.
It is important to understand how vzctl handles exit codes of action scripts. If exit code is
non-zero, then vzctl will try to undo the action for the mount and start scripts. In other
words, if the start script returns an error, then vzctl will stop VPS, and if one of the
mount scripts fails, then vzctl will dismount the VPS private area. Please note that in this
case vzctl will not execute the stop and umount scripts at all.
Caution: When executing vzctl start, both mount and start scripts run. However, if
the start script fails then neither stop nor umount scripts will run. As a result, vzctl
might be unable to dismount the VPS private area, if you set up additional mounts in the mount
scripts and dismount them in the umount scripts.
The situation with the umount and stop scripts is similar. If a script returns an error, then the
action will not be taken. Be careful since this allows to create Virtual Private Servers that are
not stoppable by vzctl.
Action scripts are located in the same directory as VPS configuration files and have names like
vpsid.action. The global scripts are named vps.mount and vps.umount, and the other
scripts have the corresponding VPS ID as part of their name. As the names of the global scripts
are fixed, they are called when any VPS is started or stopped. That is why, in these scripts you
should perform those commands that are common for all VPSs, and leave VPS-specific
commands for the scripts belonging to a particular VPS. Thus, for example, for VPS 101 the
action scripts will have names:
- Code: Select all
/etc/sysconfig/vz-scripts/vps.mount
/etc/sysconfig/vz-scripts/101.mount
/etc/sysconfig/vz-scripts/101.start
/etc/sysconfig/vz-scripts/101.stop
/etc/sysconfig/vz-scripts/101.umount
/etc/sysconfig/vz-scripts/vps.umount
For the mount and umount scripts, the environment passed is the standard environment of the
parent (i.e. vzctl) with two additional variables: $VEID and $VE_CONFFILE. The first one
holds the ID of the Virtual Private Server being mounted (started, stopped, dismounted), and the
second one holds the full path to the VPS configuration file. It is probably a bit redundant.
SWsoft introduced both variables for convenience. You can use the following fragment of the
code in bash scripts to get access to additional VPS information like $VE_PRIVATE or
$VE_ROOT locations:
- Code: Select all
#!/bin/bash
#
# This script source VPS configuration files in the same
# order as vzctl does
#
# if one of these files does not exist then something is
# really broken
[ -f /etc/sysconfig/vz ] || exit 1
[ -f $VE_CONFFILE ] || exit 1
# source both files. Note the order, it is important
. /etc/sysconfig/vz
. $VE_CONFFILE
The start and stop scripts are performed in the VPS context. If these scripts call any
external commands, these commands are taken from VPS itself. Also note that the start script
runs before any VPS tasks (including init), thus the /proc file system is not mounted in
VPS at this moment – therefore, applications using an information from /proc may be not
functional.
