Feedback

If you spot a typo in this guide, or if you have thought of a way to make this guide better, we would love to hear from you! The ideal place for your comments and suggestions is the Parallels documentation feedback page (http://www.parallels.com/en/support/usersdoc/).

CHAPTER 2

In order to make Parallels Virtuozzo Containers successfully accomplish its tasks, you need to understand how to configure the Virtuozzo Containers software correctly. This chapter explains what configuration parameters Virtuozzo Containers 4.0 has and how they affect its behavior.
Matrix of Virtuozzo Configuration Files... 11 Managing Virtuozzo Scripts.... 52
Matrix of Virtuozzo Configuration Files
There are a number of files responsible for the Virtuozzo system configuration. Most of the files are located in the /etc directory on the Hardware Node. However, some configuration files are stored in the /etc directory inside the Service Container, on the Backup Node, inside a Container, or on a dedicated server. In case a configuration file is located in a place other than the Hardware Node, we point clearly the exact position (the Service Container, etc.) where it can be found. A list of configuration files is presented in the table below:
/etc/vz/vz.conf The Virtuozzo global configuration file. This file keeps system-wide settings, affecting Container and Virtuozzo template default location, global network settings and so on. The private configuration file owned by a Container numbered <CT_ID>. The file keeps Container specific settings its resource management parameters, location of private area, IP address and so on.
/etc/vz/conf/<CT_ID>.conf
/etc/vz/conf/ve-<name>.conf.sample Sample files, containing a number of default Container configurations, which may be used as a reference for Container creation. The following samples are shipped with Virtuozzo: basic, cpanel, confixx, slm.plesk, slm.256MB, slm.512MB, slm.1024MB, slm.2048MB. You may also create your new samples customized for your own needs.
/etc/vz/conf/dists/<distribution_n The configuration files used to determine what ame>.conf scripts are to be run on performing some operations in the Container context (e.g. on adding a new IP address to the Container). These scripts are different from Virtuozzo action scripts and depend on the Linux version the given Container is running. /etc/sysconfig/vzsve /etc/sysconfig/vzagent/<file> /etc/vz/conf/networks_classes The configuration file used for the Service Container creation by vzsveinstall. Parallels Agent configuration files. The definition of network classes, used by traffic shaping and bandwidth management in Virtuozzo.

vzup2date Configuration File
The /etc/sysconfig/vzup2date/vzup2date.conf file is used by the vzup2date utility on the step of connecting to the repository with storing the latest Virtuozzo Containers updates. The parameters in this file are presented on separate lines in the following format:
<parameter_name>=<parameter_value>
The table below describes these parameters:
Parameter Server User Password HTTP_PROXY HTTP_PROXY _USER HTTP_PROXY _PASSWORD LocalRepos itoryDir LogFile Description The URL used for the connection. The user name for accessing the update server. The password for accessing the update server. The proxy server address, if you use this server. Example https://vzup2date. parallels.com user1 sample http://192.168.1.20
The user name used by the HTTP proxy server for peter your authentication. The password of the user specified in the 2wed45r HTPP_PROXY_USER parameter and used for your authentication by the HTTP proxy server. The path to the local directory on the Hardware Node /vz/vzup2date where the downloaded Virtuozzo updates are stored. By default, the /vz/vzup2date directory is used. The path to the log file on the Hardware Node /var/log/vzup2date. containing the information on Virtuozzo updates. By log default, the /var/log/vzup2date.log file is used.
Not all the possible parameters should be necessarily present in this file. In fact, all the parameters are optional, i.e. if they are missing from this file, the vzup2date utility will ask for the user input without suggesting its own variant taken from this file.
vzup2date-mirror Configuration File
The vzup2date-mirror configuration file is used by the vzup2date-mirror utility for determining the connection parameters of the repository with Parallels Virtuozzo system and templates updates and deciding what updates to download to the local mirror. The parameters in this file are presented on separate lines in the following format:
The options that can be specified in the vzup2date.conf file are described in the table below:
Parameter Server Description The URL used for the connection. As a rule, this parameter is set automatically and does not need to be modified. User Example https://vzup2date. swsoft.com
The user name for accessing the update server. user1 As a rule, this parameter is set automatically and does not need to be modified.

Password

The password for accessing the update server. sample As a rule, this parameter is set automatically and does not need to be modified.
The proxy server address, if you use this http://192.168.1.20 server.
HTTP_PROXY_USER The user name used by the HTTP proxy server peter for your authentication. HTTP_PROXY_PASS The password of the user specified in the 2wed45r WORD HTTP_PROXY_USER parameter and used for your authentication by the HTTP proxy server. LocalRepository The local directory where the mirror is to be /var/www/html Root located and all the required packages are to be stored after the execution of vzup2datemirror. This parameter can be overwritten by the local_repo_path parameter of the vzup2date-mirror utility (to learn more about local_repo_path, see the vzup2date-mirror subsection).

PING_EXIT

HTTP_PROXY=hostname Optional. The hostname or the IP address and the port number of the [:port] HTTP proxy server through which a VPN between your Node and the Parallels support server is to be established. This parameter overrides the HTTP_PROXY parameter set in the /etc/vz/vz.conf file on the Node. If the HTTP_PROXY parameter is not specified in either of the files, Virtuozzo Support Tool looks for the http_proxy environment variable on the Node and takes its value for establishing a VPN. HTTP_PROXY_USER Optional. The user name used by the HTTP proxy server for your authentication.
HTTP_PROXY_PASSWORD Optional. The password of the user specified in the HTTP_PROXY_USER parameter and used for your authentication by the HTTP proxy server.
Note: You are not recommended to change any of the aforementioned parameters. Modify them only if you are dead certain of your actions (for example, you have received the corresponding information from Parallels).
vzreport Configuration File
The /etc/vzreport.conf file is used by the vzreport utility to submit a problem report to the Parallels support team. The parameters in this file are presented on separate lines in the following format:
Parameter SUBMIT_URI COLLECTOR_SCRIPT Description The Uniform Resource Identifier (URI) of the Parallels support server to be used to receive and gather your problem reports. The path to the file on your Node where the information on your problems reports is collected. This is the same data that is sent to the Parallels support server. The hostname or the IP address of the HTTP proxy server through which your problem report will be sent to the Parallels support team. The user name used by the HTTP proxy server for your authentication. The password of the user specified in the HTTP_PROXY_USER parameter and used for your authentication by the HTTP proxy server.
HTTP_PROXY HTTP_PROXY_USER HTTP_PROXY_PASSWORD
Not all the possible parameters should be necessarily present in this file. In fact, all the parameters are optional except for the SUBMIT_URI parameter which should be specified to tell the vzreport utility where to send your problem report.

Kernel Parameters

There is a number of kernel limits that should be set for the Virtuozzo Containers software to work correctly. Virtuozzo Containers 4.0 is shipped with a tuned /etc/sysctl.conf file. Understanding what parameters were changed is essential for running the required number of Containers. Below is the contents of the /etc/sysctl.conf file as shipped with Virtuozzo Containers:

Parameter HOSTS Description The list of hosts to be monitored delimited by spaces. Both hostnames and IP addresses are allowed. E-mail addresses to receive the alerts. Must be separated by spaces. Default value

EMAIL_ADDRESSES

EMAIL_NOTIFICATIONS
The types of notifications to be sent to the specified e-mail address(es).
SYSTEM_UP SYSTEM_DOWN DISK_OK DISK_BAD INODES_NORM INODES_HIGH HDDBUSY_NORM HDDBUSY_HIGH SSH_UP SSH_DOWN VZSTAT_OK VZSTAT_BAD LOADAVG_NORM LOADAVG_HIGH UNINT_NORM UNINT_HIGH MEMLATM_NORM MEMLATM_HIGH MEMLATA_NORM MEMLATA_HIGH CPULATM_NORM CPULATM_HIGH CPULATA_NORM CPULATA_HIGH SWAPIN_NORM SWAPIN_HIGH SWAPOUT_NORM SWAPOUT_HIGH

CUSTOM_ACTION

The program to send alerts of a customized type (e.g. via ICQ or SMS). Options passed as the command line parameters of the program specified by CUSTOM_ACTION. Must be separated by spaces. Periodicity of checking up registered Nodes, in seconds. the

CUSTOM_LIST

POLL_PERIOD CHK_MAX_FAILS
After this number of unsuccessful attempts to reach a Node, the Node is dead alert is sent. The average number of processes on the Node. When this value is exceeded, an alert is sent. The number of uninterruptable sleeping processes (in the D state). When this value is exceeded, an alert is sent.

LOAD_AVG

PROC_UNINT
The maximal process scheduling latency, in milliseconds. When this value is exceeded, an alert is sent. The average process scheduling latency, in milliseconds. When this value is exceeded, an alert is sent. The maximal memory allocation latency, in milliseconds. When this value is exceeded, an alert is sent. The average memory allocation latency, in milliseconds. When this value is exceeded, an alert is sent. The swap in activity, in Mb/s. When this value is exceeded, an alert is sent. The swap out activity, in Mb/s. When this value is exceeded, an alert is sent. The percentage of free disk inodes. When the actual value becomes less than this value, an alert is sent. The percentage of free disk space. When the actual value becomes less than this value, an alert is sent.

CPU_LAT_AVG_ERR

MEM_LAT_AVG_ERR

BACKUP_LOADAVG_MAX

BACKUP_LIMIT_TIME

Per-Container parameters

Parameter Description Default Value

BACKUP_CHAIN_LEN

An incremental backup parameter. After this 7 number of incremental backups, a full backup is performed. On Virtuozzo 4.0 Hardware Nodes, this option is relevant only for the vzbackup and vzrestore utilities when they are run in the compatibility mode.

BACKUP_CHAIN_DAYS

An incremental backup parameter. After this 7 number of days a full backup is performed. On Virtuozzo 4.0 Hardware Nodes, this option is relevant only for the vzbackup and vzrestore utilities when they are run in the compatibility mode.

BACKUP_KEEP_MAX

The number of backups to store. Only full and 3 plain full backups are accounted. If a regular backup is being performed that exceeds this number, the oldest backup is automatically deleted. This parameter is effective only if the p option is specified with the vzbackup utility. If there is no -p option, the number of backups to store is not limited whatever the value of this parameter. On Virtuozzo 4.0 Hardware Nodes, this option is relevant only for the vzbackup and vzrestore utilities when they are run in the compatibility mode.
If you want to rewrite the per-Node parameters for a particular Hardware Node, you should create a new configuration file named <node>.conf and put it to the backup directory (defined by the BACKUP_DIR parameter in the global backup configuration file.
vzrhnproxy Configuration File
This file (/etc/vz/pkgproxy/rhn.conf) is the configuration file for vzrhnproxy - a special utility which can be used on any RHEL-based server (e.g. RHEL 4 or 5, Fedora Core 5 or , CentOS 4 or 5) to create RHN (Red Hat Network) Proxy Servers allowing you to effectively manage the RPM packages included in the RHEL 4 and 5 OS EZ templates. The parameters in this file are presented on separate lines in the following format: <parameter_name>=<parameter_value> The table below describes these parameters:
Parameter Name REDHAT_LOGIN REDHAT_PASSWORD HTTP_PROXY HTTP_PROXY_USER HTTP_PROXY_PASSWORD EMAIL PRE_DOWNLOAD Description The user name for logging in to Red Hat Network. The password of the user specified as the value of the REDHAT_LOGIN parameter. The hostname or the IP address and the port number of the HTTP proxy server, if you use any to connect to the Internet. The user name used by the HTTP proxy server for your authentication. The password of the user specified in the HTTP_PROXY_USER parameter and used for your authentication by the HTTP proxy server. The destination of all tracebacks. The names of the packages to be downloaded when running the vzrhnproxy update command. The names of the packages listed as the value of this parameter should correspond to the names of real packages in the RHEL repository in Red Hat Network and can be specified as regular expressions (e.g. perl.*).

EXPIRED UNKNOWN INACTIVE

The license file matches the Hardware Node ID but has expired and, therefore, could not be loaded into the kernel. No Virtuozzo support has been detected in the running kernel. The license file the utility parses is valid; however, another license is currently active in the kernel.

Migration Utilities

vzmigrate
This command is used for moving Containers to another system with minimal downtime. It has the following syntax:
vzmigrate [options] Destination_Node {Container_list}
{CT_list} is a list of <CT_ID>[:<new_CT_ID>] pairs. A new Container ID parameter is needed in case both the Source Node (the one where you run the vzmigrate command) and the Destination Node have a Container with the ID of <CT_ID>. You can specify multiple Containers at once for migration. The following options can be used with vzmigrate:
-s, --nostart Do not attempt to start the Container on the Destination Hardware Node after its successful migration if the Container was running on the Source Hardware Node prior to the migration. This option does not have any effect if the Container was not running on the Source Hardware Node. This option takes precedence of the REMOVEMIGRATED setting from the global configuration file. If yes is specified, then the Container private area and configuration file will be deleted after successful migration. If no is specified, the private area and configuration file will be left on the Source Node and have the.migrated suffix appended to them.

-r, --remove-area yes|no

-f, --nodeps [=[all][,cpu_check] [,disk_space] [,technologies] [,license][,rate]]
During its execution, vzmigrate performs a number of checks on the Destination Node (e.g. it verifies that all OS and application templates required for the Container are present on the Destination Node) and if some checks fail, exits with an error. This option allows you to bypass all checks and migrate the Container. If you specify this option for a running Container, the Container will not be automatically started on the Destination Node. You should manually start it after adding the missing templates. You can additionally use one or several of the following parameters with this option: all: do not perform any checks on the Destination Node; cpu_check: do not check the CPU capabilities of the Destination Node; disk_space: do not check the amount of disk space on the Destination Node; technologies: do not check a set of technologies provided by the Virtuozzo kernel on the Destination Node (please see the description of the TECHNOLOGIES parameter in the Container Configuration File (p. 21) subsection for details); license: do not check the license installed on the Destination Node; rate: do not check the value of the RATE parameter in the Virtuozzo global file.

The command requires only the ID of the Container where the OS EZ template is to be upgraded to perform all the tasks necessary to complete the upgrade procedure. Currently, you can upgrade the following OS EZ template inside your Containers: fedora-core-4-x86 which can be upgraded to fedora-core-5-x86. To complete this upgrade procedure, you should make sure that the fedora-core-5-x86 OS EZ template is installed on your Hardware Node. ubuntu-5.10-x86 which can be upgraded to ubuntu-6.06-x86. To complete this upgrade procedure, you should make sure that the ubuntu-6.06-x86 OS EZ template is installed on the Hardware Node.

vzpkg fetch

This command is used to download packages included in the corresponding OS EZ template or their updates from the remote repository to the vzpkg local cache on the Hardware Node and to prepare them for the installation on the Node. It has the following syntax:
vzpkg fetch [options] <OS_template>
You can pass the following options to vzpkg fetch:
Option -O, --os -A, --app -C, --cache Description Download packages/updates for the specified EZ OS template. Download packages/updates for EZ application templates used with the EZ specified OS template. Makes the vzpkg fetch command look for the metadata in the vzpkg local cache only. You can omit this parameter if the elapsed time from the last vzpkg cache update does not exceed the value of the parameter specified in the METADATA_EXPIRE /etc/vztt/vztt.conf file. If the elapsed time from the last vzpkg cache update does not exceed the value of the METADATA_EXPIRE parameter specified in the /etc/vztt/vztt.conf file, you should use this option to make vzpkg fetch look for the OS EZ template metadata in the remote repositories set for handling the corresponding EZ template. Forces the process of downloading packages and/or their updates to the Hardware Node.

-f, --force

Sets the debugging level to one of the specified values (from 0 to 10). 10 is the highest debug level and 0 sets the debug level to its minimal value. Disables logging to the screen and to the log file.
You can make vzpkg fetch run as a cron job (e.g. nightly) checking for available packages or packages updates for your EZ templates and keeping them in the local cache. Having all the necessary packages in the vzpkg local cache can greatly speed up the execution of the vzpkg install, vzpkg update, or vzpkg create cache commands since the packages are available locally and there is no need to check for them in the corresponding remote repositories.

vzpkg clean

This command is used to remove the software packages, their headers, and metadata downloaded to the Hardware Node from the repository during the vzpkg execution (e.g. while caching an OS EZ template or adding an application EZ template to a Container for the first time). It has the following syntax:

--post-cache file

--pre-install file

--post-install file

--pre-upgrade file

--post-upgrade file

--pre-update file

--post-update file

--pre-remove file

--post-remove file

The path to the script which will be executed by the vzpkg remove command after removing the application EZ template from the Container. This script is executed in the Container context and relevant for application EZ templates only. The path to the file storing a list of environment variables. The variables should be set in the form of key=value. The variables specified in this file are used when running the vzpkg create cache and vzpkg update cache commands and exported to the Container environment during the EZ template scripts execution. The path to the file containing the information on the EZ template. You can specify several files and separate them by commas. Creates the package specification file only. Creates the package source file only. Displays the utility usage and exits.

--environment file

-d, --doc file -s, --spec-only -r, --srpm -h, --help
The utility requires only the metafile to create an EZ template and save it as a software package (please see the next subsection for information on EZ template metafiles). However, you can set a number of scripts to be executed on different stages of the EZ template lifecycle (e.g. upon its installing on the Hardware Node or after its removing from the Container) or use other options listed in the table above. Notes: 1. vzmktmpl is part of the vztt-build package. This package is located in the /virtuozzo/RPMS directory of your Virtuozzo distribution and is not installed during the Virtuozzo 4.0 installation. So, before you can start using the vzmktmpl utility, you should first install the vztt-build package on your Hardware Node with the rpm -i command. 2. We recommend that you use the sample scripts located in the /usr/share/vztt/samples directory on your Node as the basis for creating your own scripts.

vzpkglink [options] CT_ID pkgset/VERSION
where CT_ID is the ID of the Container in question, pkgset is the name of the template installed on the Node, and VERSION - its version indicated usually by the 8-digit number (YYYYMMDD). The options that can be used with the utility are these:
Option -h, --help Description Display the help on the utility.
-q, --quiet --version -v, -verbose -t, --test -f, --force -c, --countlimit
Print only error messages, if any. Print the program version and exit. Print additional debugging information. Another -v option increases verbosity. Do not link the specified Container to the specified template, just evaluate the possibility of it. Skip checking the compatibility of the Container with the specified template. This option sets the minimal percentage of the number of files inside the Container that can be linked to the files in the template area in relation to the total number of files in the template. If the real percentage is less than that specified with this option, the utility does not perform the linking. The default value is 50 (per cent). This option sets the minimal percentage of the total size of files inside the Container that can be linked to the files in the template area in relation to the total size of files in the template. If the real percentage is less than that specified with this option, the utility does not perform the linking. The default value is 50 (per cent).

-s, --sizelimit

vzpkgrm
This utility is used to roll back an application or OS template update from a Container. It has the following syntax:
vzpkgrm [options] <CT_ID> <template>[/<version>].
This command will downgrade a template (<template>) to the previous installed version in the Container with the id of <CT_ID>. If the <version> parameter is specified, vzpkgrm will downgrade the template to this particular version. You may specify a number of templates for downgrading. It can be useful, for example, if the templates have complex interdependencies. The vzpkgrm utility handles these dependencies automatically. The options available to this command are:
-h, --help -q, --quiet -v, --verbose -f, --force Display the usage info and exit. Suppress warning messages and progress bar. Verbose mode. Force template un-installation. This option tells Container package manager to disregard unresolved dependencies and file conflicts with other packages installed in the Container. In case of RPM-based Containers, this option is translated into -nodeps -force switches of RPM invocation. It is not recommended to use this option since it could break consistency of package manager database inside the Container. By default, vzpkgrm does not remove the application template completely, it downgrades it to the previous available version. This option allows complete removal of the template from the Container.

-r, --remove

A Container has to be running in order to roll back a template or template upgrade from it.

vzpkgcache

This utility creates a tarball (cache) for OS templates. You should run this utility before you can use a newly installed OS template for creating Containers. It has the following syntax:
vzpkgcache [options] [PKGSET [/VERSION]]
This utility checks the configuration files of all the templates installed on the Hardware Node and if it finds an OS template for which no tar archive exists, it starts installing all packages listed in the configuration file and creates an archive at the end. This allows to greatly speed up the creation of new Containers: instead of installing all the packages comprising a Linux distribution, vzctl just unpacks the archive. Normally you run vzpkgcache without any options. However, it understands the following options:
-t, --tmpldir, --template <dir> Allows you to specify a directory where to look for templates. By default, the $TEMPLATE directory from the global Virtuozzo configuration file (/etc/vz/vz.conf) is used. Specifies the log file location. By /var/log/vzpkgcache.log is used. default,
-l, --logfile <file> --tmpdir <dir> -r, --remove
The directory where to keep intermediate files. By default, /vz/tmp is used. Remove the cache for the templates specified in the command line (PKGSET/VERSION). This option requires an explicit list of package sets (with or without version), i.e. there is no default action to remove all archives. Quiet mode: the progress bar is turned off.

-q, --quiet

Supplementary Tools

vzup2date

The vzup2date utility is used to update your Virtuozzo software and templates and keep them at the most recent version. It has the following syntax:
vzup2date [-s|-t|-z] [-m interactive] vzup2date [config_options] [-s|-t|-z] -m {batch|messages} \ <command> [command_options] [filters] [update_IDs] vzup2date {-?|--help}
The vzup2date utility can be launched in two modes: In the graphical mode: in this case vzup2date should be used with the -s, -t, and -z switches only or without any parameters at all. You can also specify the -m interactive switch to explicitly indicate that vzup2date is to be run in the graphical mode. Detailed information on how to run the vzup2date utility in the graphical mode is given in the Keeping Your Virtuozzo System Up-to-Date chapter of Parallels Virtuozzo Containers User's Guide. In the command line mode containing two submodes: the batch submode and the messages submode. To run vzup2date in the command line mode, you should specify either the -m batch switch or -m messages switch for executing vzup2date in the batch or messages submodes, respectively. Both submodes are meant to update Virtuozzo in the unattended mode and have the identical syntax; however, they are different in their output. The batch submode output is more user friendly than the messages submode one which is mostly suitable for machine processing. The following options can be passed to vzup2date in both modes - graphical and command line:

vzstat [-l] [-d X] [-p CT_ID] [-b|-v] [-t]
Here is the description of the command line parameters:
-l -d delay -p CT_ID -b Print information once and exit immediately. Specifies the delay between screen updates. Can be changed on the fly by the t interactive command. Default is 1 sec. Monitor only Containers with specified CT_ID. This flag can be given up to twenty times, in form -p CT_ID1 -p CT_ID2. This option is not available interactively. "Brief" mode. Minimal details level. Shows only one summary line about each monitoring subsystem. By default, "standard" details level is in use. Valid levels are "brief", "standard" and "verbose". Can be set on the fly by the b interactive command. See also the -v command line option and s and v interactive commands. "Verbose" mode. Provides maximum details about all monitored subsystems. Can be set on the fly by the v interactive command. See also the -b command line option and b and s interactive commands. Text mode, provides information once. It is printed in terse form, suitable for parsing by other programs. All output data are not aligned and numbers are not in a human readable format. In the text mode, there are no colors in the output and only the top 10 Containers sorted by their CPU usage are shown.
vzstat is able to display the following information:
Type of Information Uptime Description This line displays the time for which the system has been up, and three "load averages" for the system. The load averages are the average number of processes ready to run during the last 1, 5 and 15 minutes. This line is just like the output of uptime(1). Example Toggling by
1:22am, up 1:31, l 2 users, load average: 0.00, 0.06, 0.33
Containers and The total number of Containers and processes processes running at the time of the last update. The output is also broken down into the number of tasks which are running, sleeping, uninterruptable, zombie, or stopped.
CTNum 102, procs p 467: running 12, sleeping 455, unint 0, zombie 0, stopped 0

CPU states

Shows the percentage of CPU time used by all Containers (except for Container 0) and by Container 0, the CPU time spent in the user mode, in the system mode, and being idle, and the maximal/average scheduling latency in ms. The scheduling latency is the time spent by the processes in the system awaiting for scheduling. The statistics on the memory usage, including the total available memory, free memory, and maximal/average memory allocation latency. The free memory is displayed both for the low and high memory. The low memory is the sum of the DMA and Normal zones memory and the high memory is the High zone memory. Memory allocation latency is the time required to allocate memory inside the kernel in ms. An excessive allocation latency can be a sign of Node's overload.

CPU [ OK ]: CTs c 43%, CT0 12%, user 41%, sys 13%, idle 45%, lat(ms) 3/2
Mem [ OK ]: m, M total 755MB, free 671MB/0MB (low/high), lat(ms) 10/7.
Memory zones Information on the memory zones state. This information information includes: the total size of the memory zone in MB, the size of active and inactive lists, of the free memory and zone limits. Memory zones Information on the memory zones fragmentation fragmentation. This information describes how much system memory is fragmented and which is the biggest block size possible to allocate atomically. The first number before * is a number of blocks and the second is a block size in pages. Memory allocation latency
ZONE1 (Normal): m, M size 752MB, act 29MB, inact 31MB, free 658MB (0/1/2) fragm 2*1 3*2 m, M 15*4 22*8 25*16 12*32 4*64 0*128 1*256 326*512".
Memory allocation latency is an average time Mem lat (ms): A0 m, M spent in the kernel memory allocator for 0, K0 0, U0 1, different memory type requests. Any memory K1 3, Utype is coded as XY, where X is A for GFP_ATOMIC, K for GFP_KERNEL and U for GFP_USER, and Y denotes the allocation request order, i.e. Y=0 for order=0 and 1 for order=1. Slab pages: m, M 13MB/13MB (ino 8MB, de 1MB, bh 1MB, pb 0MB)
Slab cache Slab cache information includes: the total slab information cache size/real cache size divided into the inode cache size, dentry cache size, buffer heads cache size and page beancounters cache size. The real cache size is the size to which the cache can be shrunk, i.e. it is always less than the total cache size. Swap The statistics on the used swap space, including the total swap space, the available swap space and the speed of swap-in/swap-out activity in MB/s.
Swap [ OK ]: tot w, W 1004MB, free 1004MB, in 0.000MB/s, out 0.000MB/s

Swap latency

The swap operations latency. This includes the swap-in count, the swap-in maximal/average latency in ms, the swap-out count, the swap-out maximal/average latency in ms, and the maximal/average CPU time spent for the swapout.
Swap lat: si 0, w, W 0/0 ms, so 0, 0/0 ms, 0/0 cpu ms

Swap cache

The swap cache information includes the Swap cache: add w, W number of addition, deletion, and find 0, del 0, find 0/0 operations respecting the swap cache. The network statistics summary includes the total incoming traffic speed in MB/s and incoming packets/s, and outgoing traffic speed in MB/s and outgoing packets/s. Provides the network statistics summary for a particular Ethernet interface, including its total incoming traffic speed in MB/s and incoming packets/s, and outgoing traffic speed in MB/s and outgoing packets/s. Net [ OK ]: tot n, N in 1.020MB/s 267pkt/s, out 0.001MB/s 1pkt/s eth0: in n, N 0.000MB/s 3pkt/s, out 0.001MB/s 1pkt/s

Network information

Network interface information

Disks statistics

The disks statistics summary including the Disks [ OK ]: in d, D 0.000MB/s, out writing and reading activity in MB/s. 0.000MB/s

Parallels Agent (or Parallels Agent Protocol) is an XML-based protocol used to monitor and manage a Hardware Node. The Parallels Agent software implements this protocol and is a backend for the Parallels Management Console.
About Parallels Virtuozzo Containers 7 About This Guide 8 Action Scripts 11, 53, 56, 62, 94 Applications 21, 56, 64, 152 Available Commands 131 accessing 59, 74 backing up 94 configuring 59, 64, 82 creating 59, 60 destroying 59, 62 disk quota 83 inodes 83 listing 77, 78 mounting 59, 63 recovering 59, 75 reinstalling 59, 75 restarting 59, 62 restoring 59 starting/stopping 59, 62 Container Configuration File 21
Backing-Up Utilities 94 Backup Configuration File 46
Configuration Files backup 11, 46 con 152 Container 11, 21 creating 150 global 11, 13 Linux distribution 11, 30 matrix 11 offline services 11, 39 protocol 11 scaling 151 sysctl 11, 38 validating 152 vzkeytools 11 vzlmond 39 vzreport 11, 37 vzrmond 11, 42 vzstat 11, 40 vzstatrep 45 vzup2date 11, 33 vzvpn 11, 36 Configuring Virtuozzo Containers 4.Container
Documentation Conventions 8
EZ Template adding to Container 99 application 56, 99, 101, 103, 106, 107, 108 caching 56, 110, 111 cleaning 56, 99, 115 creating 56, 117 installing 56, 99, 106 listing 56, 99, 101 management tools 56, 99 OS 56, 99, 101, 103, 107, 110, 111 removing 56, 99, 108 scripts 117 updating 56, 99, 107 EZ Template Management Utilities 99

Feedback 10

Getting Help 9 Global Virtuozzo Configuration File 13 Glossary 159

HN See Hardware

Host OS 53, 159 Hostname Container 13, 21, 30, 59, 64 Hardware Node 45, 153 Parallels support server 36 proxy server 13, 36, 37
Backup 11, 46 Hardware 11, 13, 21, 30, 36, 37, 39, 45, 46, 56, 59, 64, 123, 140, 146, 147, 153, 154 Monitor 11, 13, 45
Offline Management 64 Offline Management Configuration Files 39 Organization of This Guide 8 Overview 53
IP Address Container 21, 39, 59, 64, 147 DNS server 21, 64 Hardware Node 45, 153 Parallels support server 36 proxy server 13, 36, 37 iptables 13, 21, 64
Parallels Agent 11, 159 Password Container user 59, 64 setting 59, 64 Plesk 11, 13, 39, 64 Preface 6 Problem Report 154 Processes viewing 143
Kernel 11, 38 2.4 129, 152 2.6 13, 64, 152 Kernel Parameters 38

Feedback

If you spot a typo in this guide, or if you have thought of a way to make this guide better, we would love to hear from you! The ideal place for your comments and suggestions is the Parallels documentation feedback page (http://www.parallels.com/en/support/usersdoc/).

CHAPTER 2

About Virtuozzo Containers Software.... 19 Distinctive Features of Parallels Virtuozzo Containers 4.0.. 21 Main Principles of Virtuozzo Operation... 24 Hardware Node Availability Considerations.. 33
About Virtuozzo Containers Software
What is Parallels Virtuozzo
Parallels Virtuozzo Containers is a patented OS virtualization solution. Virtuozzo Containers 4.0 creates isolated partitions or Containers on a single physical server and OS instance to utilize hardware, software, data center and management effort with maximum efficiency. The basic Virtuozzo capabilities are: Intelligent Partitioning - Division of a server into as many as hundreds of Containers with full server functionality. Complete Isolation - Containers are secure and have full functional, fault and performance isolation. Dynamic Resource Allocation - CPU, memory, network, disk and I/O can be changed without rebooting. Mass Management - Suite of tools and templates for automated, multi-Container and multi-server administration. The diagram below represents a typical model of the Virtuozzo-based system structure:
Figure 1: Virtuozzo Containers OS Virtualization
The Parallels Virtuozzo OS virtualization model is streamlined for the best performance, management, and efficiency. At the base resides a standard Host operating system which can be either Windows or Linux. Next is the virtualization layer with a proprietary file system and a kernel service abstraction layer that ensure the isolation and security of resources between different Containers. The virtualization layer makes each Container appear as a standalone server. Finally, the Container itself houses the application or workload. The Parallels Virtuozzo OS virtualization solution has the highest efficiency and manageability making it the best solution for organizations concerned with containing the IT infrastructure and maximizing the resource utilization. The Parallels Virtuozzo complete set of management tools and unique architecture makes it the perfect solution for easily maintaining, monitoring, and managing virtualized server resources for consolidation and business continuity configurations.

Virtuozzo Applications

Parallels Virtuozzo Containers is often bundled with HSPComplete, a comprehensive solution for Hosting Service Providers, based on the Virtuozzo technology. Virtuozzo Containers 4.0 allows Hosting Service Providers to: Have hundreds of customers with their individual full-featured virtual private servers (Containers) sharing a single physical server; Provide each customer with a guaranteed Quality of Service; Transparently move customers and their environments between servers, without any manual reconfiguration. While Virtuozzo Containers 4.0 is effectively coupled with HSPComplete as well as with other hosting automation solutions, the scope of its application is not limited to them. If you administer a number of Linux dedicated servers within an enterprise, each of which runs a specific service, you can use Virtuozzo Containers 4.0 to consolidate all these servers onto a single sever without losing a bit of valuable information and without compromising performance. Containers behave just like an isolated stand-alone server: Each Container has its own processes, users, files and provides full root shell access; Each Container has its own IP addresses, port numbers, filtering and routing rules; Each Container can have its own configuration for the system and application software, as well as its own versions of system libraries. It is possible to install or customize software packages inside a Container independently from other Containers or the host system. Multiple distributions of a package can be run on one and the same Linux box. In fact, hundreds of servers may be grouped together in this way. Besides the evident advantages of such consolidation (increased facility of administration and the like), there are some you might not even have thought of, say, cutting down electricity bills by times! Virtuozzo Containers 4.0 proves invaluable for IT educational institutions that can now provide every student with a personal Linux server, which can be monitored and managed remotely. Software development companies may use Containers for testing purposes and the like. Thus, The Virtuozzo Containers software can be efficiently applied in a wide range of areas: web hosting, enterprise server consolidation, software development and testing, user training, and so on.

# vzctl create 101 --ostemplate redhat-el5-x86 -config basic Creating Container private area (redhat-el5-x86) Container is mounted Postcreate action done Container is unmounted Container private area was created Delete port redirection Adding port redirection to Container(1): 4643 8443
In this case, the Virtuozzo Containers software will create a Container with ID 101, the private area based on the redhat-el5-x86 OS EZ template, and configuration parameters taken from the ve-basic.conf-sample sample configuration file. If you specify neither an OS template nor a sample configuration, vzctl will try to take the corresponding values from the global Virtuozzo configuration file (/etc/vz/vz.conf). So you can set the default values in this file using your favorite text file editor, for example:
DEF_OSTEMPLATE=".redhat-el5-x86" CONFIGFILE="basic"
and do without specifying these parameters each time you create a new Container. Please keep in mind that the. symbol before the template name in the DEF_OSTEMPLATE parameter is used to indicate that the Container being created is to be based on an OS EZ template; otherwise, it will denote an OS standard template (detailed information on OS standard templates and how to create Containers on the basis of these templates is provided in the Parallels Virtuozzo Containers Templates Management Guide). Now you can create a Container with ID 101 with the following command:
# vzctl create 101 Creating Container private area (redhat-el5-x86) Container is mounted Postcreate action done Container is unmounted Container private area was created Delete port redirection Adding port redirection to Container(1): 4643 8443
In principle, now you are ready to start your newly created Container. However, typically you need to set its network IP address, hostname, DNS server address and root password before starting the Container for the first time.
Creating Containers in Parallels Management Console
Parallels Management Console uses one wizard both to create a Container and to initially configure it. You can launch this wizard by selecting the Virtuozzo Containers item in the left pane and choosing the Create Container option on the Action menu:
Figure 7: Management Console - Creating New Container The main Container parameters, including the templates and resource management parameters, can be retrieved on the basis of the Container configuration sample indicated in the very first option (detailed information on Container configuration samples is provided in the Managing Container Resources Configurations section (p. 158)). After you have decided on the Container configuration sample, you are supposed to define the number of Containers you wish to create in the Number of Containers to create field. By default, you are offered to create one Container. Besides, you can:

Figure 47: Management Console - Viewing Container Quota Statistics To check the second-level disk quota parameters for any group or user of the given Container, perform Steps 1 thru 5 as is indicated in the previous section.
Configuring Container Disk I/O Priority Level
Virtuozzo Containers 4.0 provides you with the capability of configuring the Container disk I/O (input/output) priority level. The higher the Container I/O priority level, the more time the Container will get for its disk I/O activities as compared to the other Containers on the Node. By default, any Container on the Hardware Node has the I/O priority level set to 4. However, you can change the current Container I/O priority level in the range from 0 to 7 using the -ioprio option of the vzctl set command. For example, you can issue the following command to set the I/O priority of Container 101 to 6:
# vzctl set 101 --ioprio 6 --save Saved parameters for Container 101
To check the I/O priority level currently applied to Container 101, you can execute the following command:
# grep IOPRIO /etc/vz/conf/101.conf IOPRIO="6"
The command output shows that the current I/O priority level is set to 6. To configure the I/O priority level of a particular Container in Parallels Management Console, do the following: 1 Click Virtuozzo Containers in the Management Console left pane, right-click the needed Container in the right pane, and choose Properties.
2 Click the Resources tab and then the Disk Quota item. 3 Double-click the ioprio parameter:
Figure 48: Management Console - Configuring Container Disk I/O Priority Level
4 In the Resource Counter Properties window, you can view the disk I/O priority level currently set for the Container and change it, if necessary, by entering the desired value (from 0 to 7) in the field provided and clicking OK.

Cleaning Up Containers

The first-level quota assigned to this or that Container essentially shows how much space may be occupied by the Container private files, i.e. not by the OS or common applications files. The real OS and application files reside in the /vz/template directory on the Hardware Node and practically do not add up to the Container quota (except for the symlinks to them located inside the Container and occupying insignificant space). However, there are situations when one and the same application or application update is installed not as a template, but separately inside each and every Container. A good example of this is the CPanel application with its robust auto-update features. If a certain version of CPanel is installed in a number of Containers, and then an update is released, CPanel automatically updates itself in all these Containers, thus creating a vast amount of identical files (not symlinks already) throughout the Containers. These files tell dramatically on the Container quotas, which may be avoided by putting all the identical files to the Hardware Node template area and creating symlinks instead of real files inside the affected Containers. The problem like the one described above can be solved in two ways: 1 A special subarea is created inside the Hardware Node template area /vz/template/vc - for housing the files identical among multiple Containers with the help of the vzcache utility.

2 If the application or application update installed directly into one or more Containers has a corresponding application template or template update installed on the Hardware Node, the real files inside the Container(s) are replaced with symlinks to the template files on the Node with the help of the vzpkglink and vzpkg link utilities. These utilities are used to create symlinks to application standard and EZ templates, respectively.
Moving Container Files to Cache Area on Hardware Node
We will illustrate the effect produced by vzcache by copying one and the same huge dummy file into two Containers. First, let us learn the disk space occupied by the whole /vz partition and by the two Containers - Container 101 and Container 102:
# df /vz Filesystem /dev/hda3 # vzctl exec 101 df Filesystem vzfs # vzctl exec 102 df Filesystem vzfs 1K-blocks 13756796 1K-blocks 1048576 1K-blocks 1048576 Used Available Use% Mounted on 11% /vz Used Available Use% Mounted on 3% / Used Available Use% Mounted on 3% /
After that, we copy the dummy file, which is around 600 Mb in size, to the root of these Containers:
# cp foo /vz/root/101 # cp foo /vz/root/102
Now check the disk space once again:
# df /vz Filesystem /dev/hda3 # vzctl exec 101 df Filesystem vzfs # vzctl exec 102 df Filesystem vzfs 1K-blocks 13756796 1K-blocks 1048576 1K-blocks 1048576 Used Available Use% Mounted on 20% /vz Used Available Use% Mounted on 61% / Used Available Use% Mounted on 61% /
We see that around 600 Mb has been added to the space occupied by each Container and, consequently, around 1.2 Gb has been added to the space used on the /vz partition. Now it's time to resort to vzcache to get rid of identical files inside the Containers:
# vzcache -v Processing VZFSv2 Container 101 VZFSv2 Container regular files Processing VZFSv2 Container 102 VZFSv2 Container regular files
During the command execution, vzcache: looks for identical files inside Container 101 and Container 102; creates the CT_UUID subdirectory (where CT_UUID denotes the Container unique identifier and can be determined by viewing the UUID parameters in the Container configuration file) within the Hardware Node template area (/vz/template/vc by default) for each Container; moves the identical files to the created subdirectories in the Hardware Node template area. Let us now take the final look at the disk space usage:

Overview

Virtuozzo Service Level Management (SLM) is a special system allowing you to configure and control the service levels provided to Container users. SLM can be used to manage the Container memory resources, i.e. to adjust the amount of memory that any Container on the Hardware Node is allowed to consume. The SLM scheme introduced in Virtuozzo Containers 3.0 for the first time has been developed to replace the UBC scheme of managing system resources parameters and, thus, to simplify the resources management inside Containers by uniting all memory-related parameters into a single slmmemorylimit parameter. Note: Detailed information on all UBC parameters is provided in the Managing UBC Resources in Parallels Virtuozzo Containers guide shipped with Virtuozzo Containers 4.0. SLM can be used to ensure that: The memory consumption by every Container on the Hardware Node does not exceed its instant memory limit. The memory usage by every Container on the Hardware Node does not exceed its average limit. The total memory consumption by all Containers does not exceed the amount of memory available on the Hardware Node and prevents the total memory from reaching the point when the Node performance begins to significantly degrade. The 'low memory' usage by all Containers on the Hardware Node does not leave the safe range.
Computing Memory Usage in SLM
As a Hardware Node administrator, you may often need to properly set the amount of memory this or that Container will be allowed to consume and, therefore, should have a clear idea of the memory computation mechanism used in the SLM scheme. On the whole, the memory usage inside every particular Container for which the SLM functionality is enabled is calculated in the same way as it would be done on a standalone server. It means that the same set of applications running inside a Container will require approximately the same amount of RAM for their functioning as it would require on any other standalone server. Consequently, the amount of memory to be allocated to any Container largely depends on the number of applications you are going to deploy inside the Container and their memory requirements. For example, if you are going to use your Container as a web server only, there is no need to allocate much RAM to this Container (e.g. no more than 50 Mb). At the same time, running such memory intensive applications as MySQL, Perl, PHP requires the memory limit be set to no less than 300 Mb. The situation above provides only the general description of memory usage inside Containers. In fact, the process of memory computation used in the SLM scheme is more complicated. It includes the calculation of the oomguarpages, kmemsize, lockedpages, and socket buffer parameters and the unification of these parameters into a single slmmemorylimit parameter. It also assumes a number of accounting rules to be taken into consideration while deciding on the amount of memory to be allocated to a Container. The main rules are given below: The memory allocated to a Container includes both memory itself and the swap space. The memory consumption inside a Container is calculated by taking into account the data sharing among applications. So, if two Containers share one and the same memory page, each Container is considered to consume half a page. As the number of Containers sharing the same memory pages grows, the memory consumption inside each of these Containers decreases. Thus, an application running inside a Container can consume much less memory than the identical application launched in the Host OS or on a standalone server. Especially much data can be shared when Containers use the same versions of applications and shared libraries (e.g. in the case of using the same versions of the apache Web server with the same set of modules and the same versions of system libraries). In such cases the difference in memory usage may reach tens of megabytes. The total amount of used memory and swap space in the system is computed on the basis of the memory consumption inside all Containers plus memory usage in the Host OS.

$SOFT: the parameter value barrier; $HARD: the parameter value limit. By default, only one alert is sent per subscription and you have to resubscribe to an alert each time after its receiving. However, you can configure the default alert policy by doing the following: 1 Click the Manage E-mail Alert Subscription link on the Hardware Node dashboard.
2 In the Manage E-mail Alert Subscription window, click the Configure button. 3 In the displayed window, you can choose one of the following options: Stop sending alerts. In this case after having received an alert, you have to resubscribe to it again. This option is selected by default. Keep sending alerts. In this case you will get alerts on a permanent basis without having to resubscribe to them each time after their receiving. Collect alerts before sending for. In this case alerts will be permanently collected by the Parallels Agent software to a special database. This database will be periodically, i.e. with the period specified in the field opposite the option name, checked and if there were any alerts gathered during the set time, the corresponding notification will be sent to your e-mail address. The alert checking time is measured in seconds and can be set either by using the spin button or entering the needed period by hand. 4 After you have chosen the right option, click OK to save the settings.
Monitoring Virtuozzo Objects Using vzsnmp Plug-in
This section provides information on how you can monitor Parallels Virtuozzo objects using the vzsnmp plug-in.
Understanding vzsnmp Basics
Starting with version 4.0, Parallels Virtuozzo Containers is provided with the vzsnmp application allowing you to monitor network and system resources on the Hardware Node and inside its Containers by means of the SNMP (Simple Network Management Protocol) protocol. The vzsnmp application includes two components - vzsnmp and vzsnmp-proxy - which are automatically installed on the Hardware Node (vzsnmp-proxy) and inside the Service Container (vzsnmp) during the Virtuozzo Containers 4.0 installation. The vzsnmp plug-in conforms to the same SMI (Structure of Management Information) rules as the data represented within the standard context of SNMP, for example: all Virtuozzo objects are organized into a tree-like hierarchy any object is made up of a series of integers corresponding to the nodes in the tree and separated by dots. The root subtree containing all Virtuozzo-related objects has the object ID of 1.3.6.1.4.1.26171.1.1 and is described in the /usr/share/snmp/mibs/SWSOFT-SMI.txt file inside the Service Container. The vzsnmp plug-in enables you to monitor a number of objects and their states in respect of the Hardware Node and its Containers (e.g. the version of Parallels Virtuozzo currently installed on your Node or the IP addresses assigned to your Containers). All the data that can be reported by the vzsnmp application is described in detail in the following subsection.

Main Operations on Services and Processes
The ability to monitor and control processes and services in your Virtuozzo system is essential because of the profound influence they have on the operation and performance of your whole system. The more you know about what each process or service is up to, the easier it will be to pinpoint and solve problems when they creep in. The most common tasks associated with managing services in the Host Operating System of the Hardware Node or inside a Container are starting, stopping, enabling, and disabling a service. For example, you might need to start a service in order to use certain server-based applications, or you might need to stop or pause a service in order to perform testing or to troubleshoot a problem. For xinetd-dependent services, you do not start and stop but enable and disable services. The services enabled in this way are started and stopped on the basis of the corresponding state of the xinetd daemon. Disabled services are not started whatever the xinetd state. The services management is mostly disabled for the Hardware Node. Practically all the services are read-only, you are able to view the information but you cannot perform any operation on them. The reason is that many Red Hat packages determine a successful stop by looking up all the processes with a specified name. If such processes exist elsewhere, they are killed with the terminate signal. Thus, all the like services in all the Hardware Node Containers might be accidentally shut down because of this. However, there are some services that can be managed by a number of administrative tools offered in Parallels Virtuozzo Containers. These tools allow a service to be managed and configured either by means of special Linux command-line utilities or via Parallels Management Console. You can do it either locally or from any server connected on the network. Besides, you can manage all the processes and services through Parallels Power Panel. All the necessary information on managing services and operations in Parallels Power Panel is provided in the comprehensive online help system and the user's manual Parallels Power Panel is supplied with. As for processes, such utilities as vzps, vztop, vzpid enable you to see what a process is doing and to control it. Sometimes, your system may experience problems such as slowness or instability, and using these utilities should help you improve your ability to track down the causes. It goes without saying that in Parallels Virtuozzo Containers you can perform all those operations on processes you can do in the common Linux system, for example, kill a process by sending a terminate signal to it. In Virtuozzo Containers 4.0, you can manage services and processes using both the command line and Parallels Management Console. Further in this chapter, both methods are described.

Managing Processes and Services
In Virtuozzo Containers 4.0, services and processes can be managed by using both the command line and Parallels Management Console. In the command line, you can manage the corresponding processes and services by using the following utilities: vzps, vzpid, vztop, and vzsetxinetd. With their help you can perform the following tasks: Print information about active processes on your Hardware Node; Display the processes activity in real time; Change the mode of the services that can be either xinetd-dependent or standalone; Identify the Container ID where a process is running by the process ID. Parallels Management Console allows you to manage the services present in the Host Operating System of the Hardware Node or in a Container. It allows you to monitor (and partially configure) the services of the Host operating system at the Hardware Node. By using Management Console, you can start, stop, restart a service, or edit its run levels.Below in this chapter detailed information on all those tasks that can be performed by means of the command line utilities and Parallels Management Console is given.
Viewing Active Processes and Services
The vzps utility can be run on the Hardware Node just as the standard Linux ps utility. It provides certain additional functionality related to monitoring separate Containers running on the Node, namely, you can use the -E switch with the vzps utility to: display the Container IDs where the processes are running; view the processes running inside a particular Container. vzps prints information about active processes on your Hardware Node. When run without any options, vzps lists only those processes that are running on the current terminal. Below is an example output of the vzps run:
$ vzps PID TTY 4684 pts/pts/1 TIME CMD 00:00:00 bash 00:00:00 vzps
Currently, the only processes assigned to the user/terminal are the bash shell and the vzps command itself. In the output, the PID (Process ID), TTY, TIME, and CMD fields are contained. TTY denotes which terminal the process is running on, TIME shows how much CPU time the process has used, and CMD is the name of the command that started the process. Note: Starting with Virtuozzo Containers 3.0, the IDs of the processes running inside Containers and displayed by running the vzps command on the Hardware Node does not coincide with the IDs of the same processes shown by running the ps command inside these Containers. As you can see, the standard vzps command just lists the basics. To get more details about the processes running on your Hardware Node, you will need to pass some command line arguments to vzps. For example, using the aux arguments with this command displays processes started by other users (a), processes with no terminal or one different from yours (x), the user who started the process and when it began (u). Besides, you can pass vzps the -E switch, which is specific for Parallels Virtuozzo Containers, to sort the processes by the Container IDs where they are running.

Figure 74: Management Console - Managing Container Adapters 4 In the right part of the window, use either the Add Interface or Remove button to create or delete the virtual network adapter. 5 Click OK.
Configuring veth Adapter Parameters
While functioning in the veth mode, each Container virtual network adapter appears as a full participant on the network to which it is connected and needs to have its own identity on this network. Fist of all, to start functioning on a TCP/IP network, a veth virtual adapter should be assigned one or several IP addresses. This can be done as follows: Note: For detailed information on all parameters that can be configured for each default Container network adapter (i.e. for the adapter operating in the venet0 mode), please turn to the Configuring Container section (p. 46).
# vzctl set 101 --ifname eth1 --ipadd 192.168.144.123 --save Saved parameters for Container 101
This command will set an IP address of 192.168.144.123 for the eth1 adapter inside Container 101. If you wish to use the Dynamic Host Configuration Protocol (DHCP) to make the eth1 adapter of Container 101 automatically receive TCP/IP configuration settings, you can issue the following command instead:
# vzctl set 101 --ifname eth1 --dhcp yes --save Saved parameters for Container 101
Any static IP address assigned to the Container virtual network adapter can be removed by executing the following command:
# vzctl set 101 --ifname eth1 --ipdel 192.168.144.123 --save Saved parameters for Container 101
You can also delete all IP addresses set for Container 101 at once:
# vzctl set 101 --ifname eth1 --ipdel all --save Saved parameters for Container 101
You may also wish to set the following parameters for a Container network adapter: one or more DNS servers that the Container virtual adapter is supposed to use:
# vzctl set 101 --ifname eth1 --nameserver 192.168.100.111 --save Saved parameters for Container 101
and a gateway to be used for routing the traffic of the Container virtual adapter:
# vzctl set 101 --ifname eth1 --gateway 192.168.111.1 --save Saved parameters for Container 101
Detailed information on all options which can be used with the vzctl set command to manage Container adapter parameters is given in Parallels Virtuozzo Containers Reference Guide and the vzctl manual pages. To configure the aforementioned adapter settings in Management Console, do the following: 1 Select the Virtuozzo Containers item under the corresponding Hardware Node name.

Updating Virtuozzo System Files
Parallels Management Console provides you with a special wizard helping you update your current Virtuozzo Containers software. The Virtuozzo System Update wizard is supposed to check and, if necessary, download and install Virtuozzo system files, i.e newest versions of the Virtuozzo core and utilities. To invoke the wizard, you should right-click the name of the Hardware Node you wish to update and select Virtuozzo Update --> Check for System Updates on the context menu (alternatively, you can follow the Check for System Updates link on the Hardware Node dashboard). The wizard will try to connect to the repository housing updated packages for the Virtuozzo software and, if the connection is successful, you will be presented with a screen containing a list of available updates for your Virtuozzo Containers installation: Note: If the connection to the update server has failed, the Update Repository Settings window is displayed allowing you to check and configure the settings to be used for connecting to the repository. Detailed information on how to change the parameters in this window is given in the Checking Virtuozzo Update Center Settings subsection.
Figure 95: Management Console - Choosing Virtuozzo Updates All updates that can be currently applied to your system are listed in the Virtuozzo Core Updates (storing the latest patches to the Virtuozzo kernel) and Virtuozzo Tools Updates (storing the latest versions of Virtuozzo command-line utilities) tables on the Select Updates screen. In this window you can do the following: If you wish to update to the latest Virtuozzo core and utilities versions, just click Finish on this screen.
If you wish to install updates of certain Virtuozzo core or utilities only, select the radio buttons next to these updates and click Finish. Please keep in mind that the uppermost update includes the functionality of all the other updates (e.g. update 4.0.0-271 includes all the functionality of update 4.0.0-270). If you wish to view detailed information on an update, expand the plus sign next to this update in the corresponding table. If you do not wish to install any updates, select the Do not install any updates button. If you are going to install a Virtuozzo core update, you can additionally specify what operations are to be performed after the update installation on the Hardware Node: If you wish your system to be automatically rebooted upon the update installation completion, leave the Disable automatic reboot check box cleared. Rebooting the Node is usually required for the changes made to the Virtuozzo kernel to take effect. If you wish the Virtuozzo System Update wizard to automatically reconfigure your system boot loader (either Lilo or Grub) on applying the update, leave the Disable automatic bootloader configuration check box cleared; otherwise, select this check box. When you are ready, click Finish to start downloading the selected updates and installing them on the Node.

Now let us create a 100-Mb Linux partition in addition to an already existing 2 GB partition on /dev/sdb1 from Container 101.
[root@ct101 root]# fdisk /dev/sdb Command (m for help): p Disk /dev/sdb: 255 heads, 63 sectors, 2231 cylinders Units = cylinders of 16065 * 512 bytes Device Boot /dev/sdb1 * Start 1 End 255 Blocks 2048256 Id 83 System Linux
Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2
First cylinder (256-2231, default 256): Using default value 256 Last cylinder or +size or +sizeM or +sizeK \ (256-2231, default 2231): +100M Command (m for help): p Disk /dev/sdb: 255 heads, 63 sectors, 2231 cylinders Units = cylinders of 16065 * 512 bytes Device Boot /dev/sdb1 * /dev/sdb2 Start End Blocks 2048256 104422+ Id System Linux Linux

Command (m for help): w

After the new partition table has been written, you can format it and mount inside the Container:
[root@ct101 root]# mke2fs /dev/sdb2 [Output of mke2fs is skipped] [root@ct101 root]# mount /dev/sdb2 /mnt [root@ct101 root]# df Filesystem 1k-blocks Used Available Use% Mounted on vzfs 898660 15% / ext1% /mnt
Remember that you have to specify all minors for the devices you want to delegate authority for; allowing to access /dev/sdb grants the permission to create, modify and delete partitions on it, but explicit permissions shall be given for partitions you allow the Container to work with.
Moving Network Adapter to Container
By default, all the Containers on a Node are connected among themselves and with the Node by means of a virtual network adapter called venet0. Starting with Virtuozzo Containers 2.6.1, there is a possibility for a Container to directly access a physical network adapter (for example, eth1). In this case the adapter becomes inaccessible to the Hardware Node itself. This is done with the help of the vzctl command:
# vzctl set 101 --netdev_add eth1 --save Add network device: eth1 Saved parameters for Container 101
Mind that the network device added to a Container in such a way has the following limitations: This network device will be accessible only to the Container whereto it has been moved, but not to the Hardware Node (Container 0) and not to all the other Containers on the Node. The port redirection mechanism is not supported for this network device. The Virtuozzo class-based traffic shaping, if set for the given Container, does not limit the bandwidth for this network device. If such a device is removed from the Container (by means of the vzctl set -netdev_del command) and added to another Container instead, all the network settings of this device are purged. To work around this problem, you should store all the device settings in the ifcfg-dev file and have this file available in the /etc/sysconfig/network-scripts directory inside all the Containers that may have access to this device (including Container 0). After the device has been added to a Container, it will be enough to issue the ifup dev command inside the Container to read the settings from the file mentioned above. Mind though that this will still not restore advanced network configuration settings, such as traffic shaping or packet filtering rules. The physical device inside a Container has no security restrictions typical for the venet virtual device. Inside the Container it will be possible to assign any IP address to this device and use it, to sniff network traffic in the promiscuous mode, and so on.

Submitting Problem Report to Technical Support
Virtuozzo Containers 4.0 is shipped with a special utility - vzreport - allowing you to compile a detailed report if you have any Virtuozzo-related problems and to automatically send it to the Parallels support team. After receiving your report, the support team will closely examine your problem and make its best to solve the problem as quickly as possible. vzreport has two modes of execution full screen and command line. By default, the utility starts in the full screen mode. However, you can force the utility to run in the command line mode by specifying any option containing your contact information (e.g. -n denoting your name) or the problem report description (e.g. -m used to provide additional information on your problem). Detailed information on all the options that can be passed to vzreport in the command line is provided in the Parallels Virtuozzo Containers Reference Guide. After running the vzreport utility in the full screen mode, the Problem Report Wizard is opened, which will guide you through a number of steps asking you to provide the necessary information to generate a problem report. On the Welcome to. screen, just click Next to proceed with the wizard. You will be presented with the following window:
Figure 116: Submitting Problem Report - Providing Necessary Information In this window you should enter your name, e-mail, and the name of your company into the corresponding fields. Make sure that you type a valid e-mail address; otherwise, the Parallels support team will not be able to contact you. In the Subject field, you should also specify what Virtuozzo problem you encountered and may provide additional information in the Problem description field which, in your opinion, can help solve the problem.
Clicking Next in the Your contact information and issue description window starts collecting Virtuozzo logs and information on your system and network settings into a special file. This file will be sent to the Parallels support team upon the completion of the wizard. The file does not contain any private information! After the utility has gathered all the necessary information on your Node, the Submit report window is displayed:
Figure 117: Submitting Problem Report - Sending Report to Parallels In this window you can do one of the following: Click the Submit button to send your problem report to the Parallels technical support team. The report is dispatched directly to Parallels by using the HTTP protocol and port 80. However, if you use an HTTP proxy server for handling all your HTTP requests and wish your problem report to be sent via this server, you should specify the hostname or IP address of the server in the /etc/vz/vz.conf configuration file on the Hardware Node as the value of the HTTP_PROXY parameter. After the problem report has been successfully sent to the Parallels support, the Congratulations window is displayed informing you: of the ID assigned to your report; you should use this ID every time you communicate with the Parallels support via e-mail or the Parallels Helpdesk support tool; that an e-mail message providing you with detailed information on your problem report has been sent to the e-mail address you specified in the E-mail field of the Your contact information and issue description window. Click the Cancel button if you do not wish to dispatch the problem report to the support team at the moment for some reason or other. You can do it later on by manually sending the generated zip file to the Parallels support team. The full path to this file is indicated in the Submit report window.

# /sbin/modprobe netconsole \ netconsole=6666@192.168.0.50/eth0,514@192.168.0.100/00:17:31:D9:D7:C8
The parameters used in this command are explained below: 6666: the port on the Hardware Node used for sending UDP messages. 192.168.0.50: the IP address assigned to the Hardware Node. eth0: the name of the network interface card installed on the Hardware Node. 514: the port on the Monitor Node used to listen to incoming UDP messages from the Hardware Node. 192.168.0.100: the IP address assigned to the Monitor Node. 00:17:31:D9:D7:C8: the MAC address of the Monitor Node (if you do not know how to find out the Monitor Node MAC address, please turn to the next subsection). If you wish the netconsole module to automatically load on the Hardware Node boot up, you need to add the following string to the /etc/rc.d/rc.local script on the Node:
/sbin/modprobe netconsole \ netconsole=6666@192.168.0.50/eth0,514@192.168.0.100/00:17:31:D9:D7:C8
Determining Monitor Node MAC Address You can execute the following command on your Hardware Node to learn the MAC address assigned to the Monitor Node (we assume that the Monitor Node has the 192.168.0.100 IP address assigned):
# /sbin/arp -n 192.168.0.100 Address HWtype HWaddress 192.168.0.100 ether 00:17:31:D9:D7:C8 Flags Mask C Iface eth0
In the example above, the Monitor Node has the MAC address of 00:17:31:D9:D7:C8 assigned.
The kernel messages sent by the netconsole module on the Hardware Node may be collected by dumping the data received on a UDP port on the Monitor Node. The simplest way to collect this data is by executing the following command on the Monitor Node:
# nc -l -u 514 > /var/log/netconsole_logs
This way the messages will be collected on the 514 UDP port (this is the same port you specified when setting up netconsole on the Hardware Node) and stored in the /var/log/netconsole_logs file on the Monitor Node. However, the collected messages will have no time stamps and the redirection to the file will become broken in the case of a Monitor Node reboot. So, we recommend that you use the ttylogd serial console daemon to maintain kernel messages on the Monitor Node. Note: Some Linux distributions (e.g. SLES 10 SP1) include the netcat utility in their distributions instead of nc. If this is your case, use netcat to collect kernel messages coming from netconsole in the same way you would use the nc utility. The ttylogd serial console daemon is used to effectively process kernel messages received from netconsole on the Monitor Node. This daemon is launched by the /etc/init.d/ttylogd script on the system startup and uses the /etc/ttylogd.conf file for the correct control parameters. Thus, all you need to do to automate the kernel messages collection on the Monitor Node is to install ttylogd and to edit appropriately its configuration file. First, you should install the daemon on the Monitor Node if you have not done so before. The corresponding package can be found in the /virtuozzo/RPMS subdirectory on your Virtuozzo Containers 4.0 CD, DVD, or in your local distribution directory: