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"
IPROOT using multiple devices
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
If you have several IPs on one vserver and want
to have different netmask for each, use the following
IPROOT using different netmask
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
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
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
This is used to set various flags. Here are the
This flags prevents the vserver from setting
new security contexts.
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.
Make the ulimit maximum user process global to the
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.
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
- Processes loosing their parent are reparent
to this process.
- getppid() done by child process of this process
- 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:
Default vserver ulimit
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.