In general, each virtual server is tied to one IP using the new set_ipv4root system call. This way several servers may run the same services without conflict. Enter the IP number (a name is also valid if defined in the DNS).

Since kernel ctx-12, you can assign more than one IP number to a vserver. Enter them separated by spaces and don't forget to enclose them with quotes.

Bu default, all IPs are configured as an IP alias on the IPROOTDEV device (if defined). If you want to attach the various IP numbers to different devices, specify the device as a prefix to the IP number like this:

IPROOT="eth0:192.168.1.2 eth1:192.168.3.1 192.168.1.4"

In the example above, the IP 192.168.1.4 will be installed as an IP alias on the device IPROOTDEV.

Use "IPROOT=0.0.0.0" or "IPROOT=" if you do not want to tie the vserver at all. It will be allowed to use any IP available on the server.

This is the network device use to setup the IP alias defined by IPROOT. This is generally eth0. If you define this variable, the IP alias will be configured when you start the virtual server and un-configure when you stop it.

Netmask used to setup the IP alias. Uses the netmask of the IPROOTDEV device by default. Seldom used.

If you have several IPs on one vserver and want to have different netmask for each, use the following syntax:

IPROOT="eth0:192.168.1.2 eth1:192.168.3.1/255.255.255.192"

192.168.1.2 will use the netmask of eth0, while 192.168.3.1 will use the specified netmask: 255.255.255.192.

Broadcast address used to setup the IP alias. Uses the broadcast of the IPROOTDEV device by default. Seldom used.

The vserver package supplies the vservers service. This service is installed in the main server. It is used to start and stop the virtual server at boot and shutdown time.

Virtual server with ONBOOT=yes will be started and stopped properly like any other services of the main server.

Once a virtual server is properly configured, it is a good idea to set this parameter to yes.

You enter here the various capability you want to grant to the vserver. By default, a vserver is left with much less capabilities than the root server. For example, a vserver is not allowed to use raw socket. This explains why the ping command fails. S_CAPS lets you enumerate the capability you want to keep in the vserver. CAP_NET_RAW will give back ping ability for example.

This is optional. In general the security context ID is selected by the kernel. An unused one is selected. If you select an ID (an integer greater than 1), make sure you select a different one for each server. Again, in most cases, you do not need to select one. Leave the line commented.

A virtual server may have a different NIS domainname than the main server. You set it here. If you leave the field empty, the vserver will inherit the same NIS domain as the root server. Enter "none" to reset the NIS domain name for this vserver.

Many services (Apache for one) use the host name to setup some defaults. A virtual server may have a different host name than the main server. It is a good idea to fill this line.

The is an optional priority level. It is an integer ranging between from -20 to 19. Well it is the nice level in fact, so -20 means the highest priority and 19 the lowest (the highest nice level). All processes in the virtual server will be locked to this level (or higher niceness).

Event root is locked and can't get more priority.

Note that this has limited usefulness. The kernel does not differentiate processes running in different security context for scheduling (for now :-) ). This means that a virtual servers running many low priority processes may nevertheless claim a large share of CPU.

This is used to set various flags. Here are the supported flags:

• lock
  This flags prevents the vserver from setting new security contexts.
• sched
  It kind of unifies the processes in a vserver from a scheduler view point. All processes are weighted as single one when compared to other processes in the real server. This prevents a vserver from taking to much CPU resources.
• nproc
  Make the ulimit maximum user process global to the vserver.
• private
  Once set on a vserver security context, no other process can enter it. Even the root server is unable to enter the context. It can see the process list using security context 1, but can't signal or trace the process.
• fakeinit
  This assigned the current process so it works like the process number 1. Using this trick, a normal /sbin/init may be run in a vserver. The /usr/sbin/vserver command will use /sbin/init to start and stop a vserver. A properly configured /etc/inittab is needed though.
  • Processes loosing their parent are reparent to this process.
  • getppid() done by child process of this process returns 1.
  • getpid() done by this process returns 1.
  • This process is not shown in /proc since process number 1 is always shown.
  • An "initpid" entry is available in /proc/*/status to tell which process is the fake init process.

This contains the command line option to the ulimit shell command. You enter here whatever parameters accepted by ulimit. Here is the default when you create a new vserver:

ULIMIT="-H -u 1000"

Normally ulimit settings only affects users independantly. So limiting a vserver this way, limit each user processes independantly in the vserver. Using special flags in the S_FLAGS option, you can make those ulimit settings global to the vserver. The example above used with the nproc parameter make the maximum number of process global. In this case, a maximum of 1000 processes is available to all users in the vserver.