Frequently Asked Questions

To talk about stuff, we need some naming. The physical machine is called 'Host' and the 'main' context running the Host Distro is called 'Host Context'. The virtual machine/distro is called 'Guest' and basically is a Distribution (Userspace) running inside a 'Guest Context'.

derjohn

With VServer you can only run Linux guests. The trick is that a guest does not run a kernel on its own (as XEN and UML do), it merely uses a virtualized host kernel-interface. VServer offers so called security contexts which make it possible to seperate one guest from each other, i.e. they cannot get data from each other. Imagine it as a chroot environment with much more security and features.

derjohn

The first public occurrence of Linux-VServer was Oct 2001. The initial mail can be found here: http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1065.html So you can expect a mature software product which does its magic quite well (And hey, we have a version > 2.0!)

derjohn

Some. Check out the wiki for ready-made guest images. But you can easily build own guest images, e.g. with Debian's debootstrap. Checkout Building Guest Systems how to do that.

derjohn

Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU not "emulate" any hardware you run a kernel on. The purpose of Linux VServer is to isolate (groups of) applications. The isolation is done by the kernel (see Overview for a more detailed comparison). You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.

derjohn

If you are new to VServer I recommend to try the latest stable kernel patch, and the latest util-vserver "alpha" release.

derjohn

We hope so. It should be as least as secure as Linux is. We consider it much much more secure though.

derjohn

For a single guest, we basically have native performance. Some tests showed insignificant overhead (about 1-2%) others ran faster than on an unpatched kernel. This is IMVHO significantly less than other solutions waste, especially if you have more than a single guest (because of the resource sharing).

derjohn

Well, this page contains all configuration options for util-vserver. The name of the page is derived from the stylesheet(s) it contains.

derjohn

Yes ....

• memory: Dynamically.
• CPU usage: Dynamically (token bucket)

derjohn

You can put limits per guest on different subsystems.

• using ulimits and rlimits (rlimit is a new feature of kernel 2.6/vs2.0.) per guest, to limit the memory consumption, the number of processes or file-handles, ... : see Resource Limits
• CPU usage : see CPU Scheduler
• disk space usage : see Disk Limits and Quota

Note that you can only offer guaranteed resource availability with some ticks at the time.

derjohn&xm

First you can read [1] and Memory Limits.

If you want a recipe, do this:

1. Check the size of memory pages. On x86 and x86_64 is usually 4 KB per page.
2. Create /etc/vserver/<guest>/rlimits/
3. Check your physical memory size on the host, e.g. with "free -m". maxram = kilobytes/pagesize.
4. Limit the guests physical RAM to value smaller then maxram:

   echo %%insertYourPagesHereSmallerThanMaxram%% > /etc/vserver/<guest>/rlimits/rss 

5. Check your swapspace, e.g. with 'swapon -s'. maxswap = swapkilobytes/pagesize.
6. Limit the guest's maximum number of as pages to a value smaller than (maxram+maxswap):

    echo %%desiredvalue%% > /etc/vserver/<guest>/rlimits/as 

It should be clear this can still lead to OOM situations. Example: You have two guests and your as limit per guest is greater than 50% of (maxram+maxswap). If both guests request their maximum at the same point in time, there will be not enough mem .....

derjohn

Well, since vs2.1.1 Linux-VServer supports a mechanism called 'I/O scheduling', which appeared in the 2.6 mainline some time ago. The mainline kernel offers several I/O schedulers:

# cat /sys/block/hdc/queue/scheduler
noop [anticipatory] deadline cfq

The default is anticipatory a.k.a. "AS". When running several guests on a host you probably want the I/O performance shared in a fair way among the different guests. The kernel comes with a "completely fair queueing" scheduler, CFQ, which can do that. (More on schedulers can be found at http://lwn.net/Articles/114770/) This is how to set the scheduler to "cfq" manually:

root# echo "cfq" > /sys/block/hdc/queue/scheduler
root# cat /sys/block/hdc/queue/scheduler
noop anticipatory deadline [cfq]

Keep in mind that you have to do it on all physical discs. So if you run an md-softraid, do it to all physical /dev/hdXYZ discs! If you run Debian there is a predefined way to set the /sys values at boot-time:

# apt-get install sysfsutils
[...]

# grep cfq /etc/sysfs.conf
block/sda/queue/scheduler = cfq
block/sdc/queue/scheduler = cfq

# /etc/init.d/sysfsutils restart

For non-vserver processes and CFQ you can set by which key the kernel decides about the fairness:

cat /sys/block/hdc/queue/iosched/key_type
pgid [tgid] uid gid

Hint: The 'key_type'-feature has been removed in the mainline kernel recently. Don't look for it any longer :(

The default is tgid, which means to share fairly among process groups. Think every guest is treated like a own process group. It's not possible to set a scheduler strategy within a guest. All processes belonging to the same guest are treated like "noop" within the guest. So: If you run apache and some ftp-server within the _same_ guest, there is no fair scheduling between them, but there is fair scheduling between the whole guest and all other guests.

And: It's possible to tune the scheduler parameters in several ways. Have a look at /sys/block/hdc/queue/....

derjohn

Well, since linux 2.6.13 processess have another priority next to the cpu nice scheduling hint, it's called io nice.

It's split into three groups, called real-time, best effort and idle. The default is best-effort, but within best-effort, you can have a niceness from 0 to and including 7. You can set this niceness by the tool ionice, which for debian is either in the package util-linux or schedutils. To change the io-niceness you need the CAP_SYS_NICE, and need to have the same uid as the processe you want to ionice.

Note: If you want to use any schedulung other than best-effort you will also need the CAP_SYS_ADMIN-flag. Be warned that this gives quite some capabilities to the vserver, not just for I/O scheduling!

If you want to increase the niceness of an I/O hogging process within a vserver you need to do:

chcontext --xid sponlp1 sudo -u '#2089' ionice -c2 -n5 -p24409

with sudo and ionice installed on the root server to increase the *nice*ness of pid 24409, with uid 2089

Groteblup

Unification is Hard Links on Steroids. Guests can 'share' common files (usually binaries and libraries) in a secure way, by creating hard links with special properties (immutable but unlinkable (removable)). The tool to identify common files and to unify them is called vunify.

derjohn

The successor of vunify, a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)

It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.

There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).

Guy-

For 'vhashify', just do these once:

mkdir /etc/vservers/.defaults/apps/vunify/hash /vservers/.hash
ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/root

Then, do this one line per vserver:

mkdir /etc/vservers/<vservername>/apps/vunify   # vhashify reuses vunify configuration

To hashify a running vserver, do (possibly from a cronjob):

vserver name-of-guest hashify

The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via vserver enter.

In order for the Oduler paramters changed.You can use this (ugly) script to convert them or do it by hand:

# cat /usr/local/sbin/vserver-convert-schedule-to-scheddir
#/bin/sh
mkdir /etc/vservers/$1/sched
sed -e 1p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/fill-rate
sed -e 2p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/interval
sed -e 3p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens
sed -e 4p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-min
sed -e 5p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-max

mv /etc/vservers/$1/schedule /etc/vservers/$1/schedule.converted.see.scheddir

# see: http://oldwiki.linux-vserver.org/Scheduler+Parameters
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html#sched

derjohn

Every VS version that runs on a kernel >= 2.6.19 offers sysctl values per guest. This has to do with the 'ipc namespace' feature that was added to the mainline kernel in version 2.6.19. Linux-VServer uses that feature to give each guest a separate 'ipc namespace' and thus 'own' sysctl values per guest. Because shmmax is such a sysctl value, you have to set it per guest.

Here is an example how to do so:

# mkdir /etc/vservers/<vserver>/sysctl/0 -p
# echo kernel.shmall > /etc/vservers/<vserver>/sysctl/0/setting
# echo 134217728 > /etc/vservers/<vserver>/sysctl/0/value
# mkdir /etc/vservers/<vserver>/sysctl/1 -p
# echo kernel.shmmax > /etc/vservers/<vserver>/sysctl/1/setting
# echo 134217728 > /etc/vservers/<vserver>/sysctl/1/value

It's also explained on the geat flower page:

1. see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html -> Look for "sysctl".

After changing those values, restart your guest, enter it and check if the values are set:

# sysctl -a | grep shm
...
kernel.shmall = 134217728
kernel.shmmax = 134217728

derjohn