Container Action Scripts

There might be situations when you need to do additional actions when a particular Container is started or stopped. For example, if you want to be able to access the server file system (or part of it) from Container 101, then you can bind mount it inside the Container manually from the server. However, after you restart the Container, your mount disappears, and you should manually type the mount command again.

Parallels Server Bare Metal allows you to automate procedures like the above by using action scripts . There are six action scripts defined in the current version of Parallels Server Bare Metal:

global `mount`	This script runs immediately after `pctl` mounts the Container private area. The Container itself is not yet running and the script is running in the server context.
`mount`	This script runs immediately after the global mount script. The Container is still not running, and the scripts is called in the server context.
`start`	After `pctl` has started a Container, it runs the Container `start` script. The script is running already in the Container context.
`stop`	This script runs before the Container is stopped, in the Container context.
`umount`	After the Container has been already stopped, the `umount` script is executed, and the script runs in the server context.
global `umount`	This script runs when `pctl` is about to dismount the Container private area. It also runs in the servercontext.

It is important to understand how pctl handles exit codes of action scripts. If exit code is non-zero, then pctl will try to undo the action for the mount and start scripts. In other words, if the start script returns an error, then pctl will stop Container, and if one of the mount scripts fails, then pctl will dismount the Container private area. Please note that in this case pctl will not execute the stop and umount scripts at all.

Caution: When executing pctl start , both mount and start scripts run. However, if the start script fails then neither stop nor umount scripts will run. As a result, pctl might be unable to dismount the Container 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 Containers that are not stoppable by pctl .

The global scripts are named vps.mount and vps.umount and located in the /etc/vz/conf directory on the server. These scripts are called when any Container on the server is started or stopped. So, you should include in these scripts those commands that are common for all Containers and leave Container-specific commands for the scripts belonging to a particular Container. Container-specific action scripts are located in the /vz/private/ CT_ID /scripts directory and have the mount , start , stop , and umount names. For example, the scripts specific for Container 101 will have the following names:

/vz/private/101/scripts/mount
/vz/private/101/scripts/start
/vz/private/101/scripts/stop
/vz/private/101/scripts/umount

For the mount and umount scripts, the environment passed is the standard environment of the parent (i.e. pctl ) with two additional variables: $VEID and $VE_CONFFILE . The first one holds the ID of the Container being mounted (started, stopped, dismounted), and the second one holds the full path to the Container configuration file. It is probably a bit redundant. Parallels introduced both variables for convenience. You can use the following fragment of the code in bash scripts to get access to additional Container information like $VE_PRIVATE or $VE_ROOT locations:

#!/bin/bash
#
# This script sources Container configuration files in the same
# order as pctl 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/vz/vz.conf
. $VE_CONFFILE

The start and stop scripts are performed in the Container context. If these scripts call any external commands, these commands are taken from the Container itself. Also note that the start script runs before any Container tasks (including init ), thus the /proc file system is not mounted inside the Container at this moment – therefore, applications using information from /proc may be not functional.

Top of page

Feedback