Difference between revisions of "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

A: 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

A: 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

A: 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. 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

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

derjohn

A: 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

A: Yes, on all SMP capable kernel architectures.

derjohn

A: Yes ....

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

derjohn

A: Yes, you can set maximum limits per guest, but you can only offer guaranteed resource availability with some ticks at the time. There is the possibility to ulimit and to rlimit. Rlimit is a new feature of kernel 2.6/vs2.0.

derjohn

A: 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

A: 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. 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

A: Device nodes allow userspace to access hardware (or virtual resources). Creating a device node inside the guest's namespace will give access to that device, so for security reasons, the number of 'given' devices is small.

derjohn

A: 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

A: 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-

A: 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 OS cache to benefit from the hardlinking, you'll have to restart the vservers.

To clean up hashified files that are no longer referenced by any vserver, do (possibly from a cronjob):

find /vservers/.hash -type f -links 1 -print0 | xargs -0 rm

Until you do this, the files still take up place even though no vservers need them.

Guy-

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

derjohn

A: Yes, but not on a shared partition for now. You need to put the guest on a separate partition, setup a vroot device (to make the quota access secure), copy that into the guest, and adjust the mtab line inside the guest.

derjohn

A: Context quotas are now called Disk Limits (so that we can tell them apart from the user/group quotas :). They are supported out of the box (with vs2.0+) for all major filesystems (ext2/3, ReiserFS, JFS)

derjohn

A: Currently it requires an additional patch, but the functionality should be available in 2.3+ soon. IPv6 has more information.

derjohn

A: For now the networking is 'Host Business' -- the host is a router, and each guest is a server. You can set the capability ICMP_RAW in the context of the guest, or even the capability CAP_NET_RAW (which would even allow to sniff interfaces of other guests!). Likely to change with ngnet.

derjohn

A. http://OpenVPS.org which is a set of scripts with a web-interface for webhosters/ISPs. http://Openvcp.org which is a distributed system (agent!) with a web-interface, with which you can build/remove guests. http://vsmon.revolutionlinux.com/ is a distributed monitoring-only solution that allows you to search for a particular vserver in your park.

derjohn

A. Old-style config refers to a single text-file that contains all the configuration settings. With new-style config the configuration is split into several directories and files. You should probably go for new-style config if you are asking.

derjohn

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

derjohn

A: First of all a single guest vserver only supports up to 16 IPs (There is a 64-IP patch available, which is in "derjohn's kernel").

Here is a little helper-script that adds a list of IPs defined in a text file, one per line.

#!/bin/bash
j=1
for i in `cat myiplist`; do
        j=$(($j+1))
        mkdir $j
        echo $i > $j/ip
        echo "24" > $j/prefix
done

derjohn

A: Yes, use iptables with SNAT to masquerade it.

iptables -t nat -I POSTROUTING -s $VSERVER_NETZ  ! -d $VSERVER_NETZ -j SNAT --to $EXT_IP

See: HowtoPrivateNetworking and

http://www.tgunkel.de/it/software/doc/linux_server.en#h3-VServer_Masquerading_SNAT (THX, [MUPPETS]Gonzo)

derjohn

A: When you shut down a guest (i.e. vserver foo stop), the IP is brought down on the host also. If this IP happens to be the primary IP of the host, the kernel will not only bring down the primary IP, but also all secondary IP addresses. But in very recent kernels, there is an option settable which prevents that nasty feature. It's called "alias promotion". You may set it via sysctl by adding net.ipv4.conf.all.promote_secondaries=1 in /etc/sysctl.conf or via sysctl command line.

derjohn

A: Simple ;) Assume you want to build a breezy guest on a sid host with IP 192.168.0.2 and hostname vubuntu, then do:

vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu

[UPDATE] Currently there are problems in building breezy under unclear circumstances, which seems to have to do with udev. If the above didnt work, try:

vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu -- --exclude=udev

In very recent versions of the utils, the problem should not occur anymore (it has to do with the 'secure-mount' if you look in the MLs)

Well, sid's debootstrap knows how to bootstrap Ubuntu linux. Make sure to have a current debootstrap package:

apt-get update
apt-get install debootstrap

The knowledge how to build ubuntu 'breezy badger' (which you probably want to be your guest at the time of writing) has been added recently.

derjohn

A: Even simpler ;) See http://www.gentoo.org/proj/en/vps/vserver-howto.xml#doc_chap3 .

gcc

A: At least on Debian, I can tell you how to do it with the new-style config. If your guest is called "derjohn" and you want it to be started somewhere at the of your bootstrap process, then do:

echo "default" > /etc/vservers/derjohn/apps/init/mark

If you want to start it earlier, please read the init script "/etc/init.d/util-vserver" to find out how to do it. In most cases you don't need to change this. On Debian the vservers are started at "20", so after most other stuff is up (networking etc.).

Besides that I created a small helper script for managing the autostart foo: ((vserver-autostart))

derjohn

A: You are probably using util-vserver <= 0.30.209, which does use dynamic network contexts internally (With 0.30.210 this fact changed). So if you compiled your kernel without dynamic contexts, you may start guests, but you can't use the network context.The solution is either to switch to .210 util (or Hollow's toolset) or compile the kernel with dynamic network contexts. SE Keyword: invalid option `nid' testme.sh

derjohn

A: Look at /etc/ssh/sshd_config of the host:

Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::

And now change the setting to

Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
ListenAddress your.hosts.ip.here  # not the guests IP! 

Then '/etc/init.d/ssh restart' on the host, after that on the guest (if you did apt-get install ssh on the guest already.)

Do I have to explain more? If the hosts sshd binds all available IP addresses on port 22 (The hosts 'sees' even all addresses of the guests!). So if the guest starts its sshd, it can't bind to port 22 any more. You need to change that setting only on the host.

(BTW: A similar approach has to be done for a lot of daemons, e.g. Apache. If the daemon does not support an explicit bind, you may use the chbind command to 'hide' IP addresses from the daemon before starting.)

derjohn

A: Before asking on the IRC channel, please check out the 'problematic programs' page: Problematic Programs

derjohn

A: Check out the Problematic Programs page and/or get my vserver-guest-ready Debian package for Debian Sid guests and check out the readme. (Hint: This is fresh stuff. Please give me feedback) [UPDATE] Since VServer Devel 2.1.1-rc18 you do not need to patch the userland tools anymore. The capabilities are masked.

derjohn

A: Use vserver-stat to find out. Example output:

CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
0       77 965.1M 334.6M  14m14s18   2m28s69   1h33m46 root server
49152    7    14M   5.2M   0m00s40   0m00s30   1h30m15 chiffon

derjohn

A: It depends.

For legacy Linux-VServer (i.e. 1.2.x), you have to replace /sbin/halt in the guests with vreboot and start rebootmgr in the host. You also need to have a <guest>.conf file in /etc/vservers for each guest. Please have a look at /etc/init.d/rebootmgr.

For Linux-VServer 2.0+, sys_reboot has been virtualized to do the right thing. No changes are needed in guests.

derjohn

A: Since Linux-VServer is an ongoing project, new features might replace old ones, some might require a development version. Legacy-interfaces are available for backward compability (which might be removed someday) with Linux-VServer 1.2.x.

derjohn

A: There are no known issues about running vserver on a preemption enabled kernel. I would like to add, that the vserver kernelhackers would probably exclude that option in 'make menuconfig' if there would be an incompatibility. Just my $.02 :)

derjohn

A: 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

A: Yes. To get a OpenVPN Server running in a guest, all networking setup has to be done on the host. This answer describes the common case and shows some pitfalls, for detailled information about OpenVPN, please consult the appropriate documentation on the OpenVPN homepage.

This is the minimal OpenVPN configuration for the Server which will be used to demonstrate how to get it running in a client:

# Networking setup
server 192.168.16.0     255.255.255.0
dev tun16
ifconfig-noexec
comp-lzo
# Certificates
dh ...
ca ...
cert ...
key ...
# Management
persist-key
keepalive 10 60
verb 4

First of all you have to prepare the host with a persistent interface in the right mode and with the right settings. This is easily done by using openvpn and the ip and route tools.

# openvpn --mktun --dev tun16
# ip link set dev tun16 txqueuelen 100
# ifconfig tun16 192.168.16.1 pointopoint 192.168.16.2 mtu 1500
# route add -net 192.168.16.0 netmask 255.255.255.0 gw 192.168.16.2

If you need different settings, openvpn will tell you the ifconfig and route commands it uses to configure the interface when being started on the host with the original config file, but without ifconfig-noexec.

Additionally, the guest needs /dev/net/tun to make OpenVPN happy. This can be created with MAKEDEV:

# cd /var/lib/vserver/<myopenvpnserver>/dev/
# ./MAKEDEV tun
  (creates the dev/net/tun device accessible by the guest - even a tap interface needs /dev/net/tun !)

Finally, the guest needs to have the tun device assigned:

# head /etc/vservers/<myopenvpnserver>/interfaces/1/*
==> /etc/vservers/<myopenvpnserver>/interfaces/1/ip <==
192.168.16.1

==> /etc/vservers/<myopenvpnserver>/interfaces/1/nodev <==
tun16

==> /etc/vservers/<myopenvpnserver>/interfaces/1/prefix <==
24
#

The client's conf may look like that:

# Basic setup
client
proto tcp-client
dev tun
remote <ipaddress>
comp-lzo
verb 4

# Certificate
ca ...

[ Based on derJohn's original answer, all errors mine ]

DavidS

A: If you have the choice make the host a 64 bit one. You can run a guest as 32 bit or as 64 bit on a 64 bit host. To run it as 32 bit, you need to compile the x86_64 (a.k.a. AMD64) with the following options:

[*] Kernel support for ELF binaries
<M> Kernel support for MISC binaries
[*] IA32 Emulation <---- without that, the entire 32bit API is not present
<M>   IA32 a.out support  

You can force the guest to behave like a 32 environment like this:

echo linux_32bit > /etc/vservers/$NAME/personality
echo i686 > /etc/vservers/$NAME/uts/machine

(thanks cehteh for the hint!)

But you can force debootstrap to put 32 bit binaries into the guest by 'export ARCH=i386';

export ARCH=i386 ; vserver build .... 

derjohn

A: I'll explain. I take as example your /tmp partition within the guest is too small, what will be likely the case if you stay with the 16MB default (vserver build mounts /tmp as 16 MB tmpfs!).

# vnamespace -e XID  mount -t tmpfs -o remount,size=256m,mode=1777 none /var/lib/vservers/<guest>/tmp/

(if there's a problem, try expanding the symlinks in the mount path)

Be warned that the guest will not recognize the change, as the /etc/mtab file is not updated when you mount like this. To permanently change the mount, edit /etc/vserver/<guest>/fstab on the host.

derjohn

A: 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

A: Here you go: http://linux-vserver.derjohn.de/ . There is also some stuff on backports.org, but my kernels are always 'devel' branch.

derjohn

Yes but right now only on the host (rootserver). Please realize that all traffic is local and will not touch the forward chain.

BeginnerFAQ

strace shows

 
sin_addr=inet_addr("xx.xx.xx.xx")}, yy) = -1 EINVAL (Invalid argument)

A: The host/guest cannot communicate with another guest on same host.

• check all netmasks on all interfaces (do they overlap) ?
• check policy routing (disable it temporary) ?
• check that lo is up (Networking within a host/guest always uses lo interface)

CommonProblems

capabilities are not enabled in kernel-setup please check that CONFIG_SECURITY_CAPABILITIES is loaded or included in the kernel. ( check with "cat /path_to_kernel/.config

IrcQuestions

Mount it via /etc/vservers/vserver-name/fstab, make sure to set the option 'dev' e.g.:

/dev/drbd0     /       xfs     rw,dev          0 0

AdrianReyer

Tagging the guest's files gives you serveral advantages, e.g. the accoutung will work properly.

Filesystem XID tagging only works on supported filesystem. Those are currently: ext2/3, reiserfs/reiser3, xfs and jfs. To activate the XID tagging you have to mount the filesystem with "-o tag" (former tagxid is outdated since VS2.2). Attention: It's _not_ possible to "-o remount,tag", you have to mount it freshly. The guests will tag their files automatiaclly. If you copy files in from the host, you have to tag them manually like this:

chxid -c xid -R /var/lib/vservers/<guest>

Note: Context 0 and 1 will see all files, guests will only be able to access untagged files and their own XID. They can see other XID files but no information about the file, e.g. no owner, no group, no permissions.

derjohn_and_gonzo_and_are

This can be related to /tmp being too small. mysqld stores temporary tables in /tmp and as such, if a lot of queries happen and /tmp runs full this can cause one query to lock up whilst creating the tmp table and all other queries waiting to acquire the lock. There are two possible solutions to that problem: a.) Modify /etc/vservers/vserver-name/fstab and assign more memory to the tmpfs of /tmp and b.) remove the /tmp entry from /etc/vservers/vserver-name/fstab completly. Especially on database servers with a rather high load the second one might be the preferred method.

sp

vkill --xid <xid> -s 15; sleep 2; vkill --xid <xid> -s 9

daniel_hozac

A guest cannot lower its nice value - and that's what 'su' does through pam_limits which sets a nice value of 0. You can see it through strace:

$ strace nice su nobody
[...]
setpriority(PRIO_PROCESS, 0, 0)         = -1 EACCES (Permission denied)

You can use 'su nobody -c nice some_cmd' instead.

(Now there's the question of why a guest process cannot lower its nice value.)

daniel_hozac&Beuc

By default, vserver uses the 'sysv' startup style, which mimics the init process by running the 3rd runlevel through '/etc/init.d/rc 3' (or '/etc/rc.d/rc 3'). Usually this 'rc' script uses a hard-coded PATH. In the case it doesn't, util-vserver also mimics init's default PATH through /etc/vservers/.defaults/apps/init/environment, or if not present /usr/local/lib/util-vserver/defaults/environment. Beware that all those default PATH usually do not include /usr/local.

daniel_hozac&Beuc

A: After a reboot you need to run the vprocunhide script. If running this script causes many errors to print on the screen, try checking the kernel you have booted with (perhaps it does not have the linux-vserver extensions enabled).

mattzerah

vnamespace -e guest mount -n -o remount,size=32m /vservers/<guest>/tmp or something like that.

derjohn/dhozac

At the time of writing, Debian Etch is the stable release of Debian and includes a 2.6.18 based kernel-package called 2.6.18-4-vserver. This currently contains a VServer 2.0.2.2-rc9. If you need more features, build an own one or take it from derjohn's ( http://linux-vserver.derjohn.de , details on derjohn's blog: http://blog.derjohn.de/snipsnap/space/start/2007-04-22/1 .

derjohn/dhozac

Unfortunately, the nagios-plugins ./configure scripts wants to ping 127.0.0.1 which is not available inside a guest. Therefore you have to build nagios-plugins outside the guest.

The easiest way to do this from the host (assuming the guest is running) is:

vnamespace -e <xid> -- chroot /vservers/<name> emerge nagios-plugins -va

Hollow

This is done from the host server:

• add the ip on the host, for example

ip addr add 194.169.123.23/24 dev eth0 

• add the ip to the guest's network context (a guests NID is the same as the XID {context ID})

naddress --add --nid <nid> --ip 194.169.123.23/24 

• enter the guest (best via ssh)
• restart the services that need to make use of the new address if required
• update the config in /etc/vserver/<servername>/interfaces to reflect the changes for the next guest restart (if desired)

BenjaminGreen

Try to run ntpdate with options -u :

ntpdate -u ntp.domain.xy

or you can use command:

chbind --nid 42 --ip 1.2.3.4 -- ntpdate ntp.domain.xy

where IP will be the IP of host.

Punkie/Bertl

A: There are three ways.

1) Mount the NFS share from the host OS and let vserver guest access it as part of it's file system.

mount --bind may also be beneficial in this scenario.

2) Use util-vserver and create a fstab.remote file in the /etc/vserver/<vserver_name> directory. Populate this with the NFS shares and they will be mounted in the context of the vserver guest.

See http://www.nongnu.org/util-vserver/doc/conf/configuration.html

3) Add capabilities to the vserver guest instance to grant sufficient rights to allow NFS mounts.

Add the following to /etc/vserver/<vserver_name>/bcapabilities

SYS_ADMIN

Add the following to /etc/vserver/<vserver_name>/ccapabilities

SECURE_MOUNT
BINARY_MOUNT

See Capabilities_and_Flags for more information about vserver capabilities.

If you want the NFS shares to be mounted when the guest starts, add them to /etc/vserver/<vserver_name>/fstab

martindk

That's because it has capabilities enabled, make sure you rebuild your distro's package passing also the `--without-capabilities` flag to configure.

Pedro Algarvio, aka, s0undt3ch

Took me a while to figure this out, and it turned out to be mentioned in the old wiki. Here is the solution on how to solve a common problem with sshd / crond, somehow related to selinux and auditing:

pam authentication (also used with openssh) enables "pam_loginuid.so" in the /etc/pam.d/* files. Comment those out as they are not necessary and will not load within a guest anyway. This probably is also necessary on updates later on, if the configs get changed. You therefore may add the following command line to a cronjob file or your software update script:

/bin/sed --in-place -e "s/^session.*required.*pam_loginuid.so/# session\trequired\tpam_loginuid.so/g" /etc/pam.d/*

patrick

Dynamic context are disabled by default and are deprecated. For example, tagxid and network checks won't be useable with dynamic ids. Now you should manually assign a explicit context to your vservers, like

echo 101 > /etc/vservers/myvserv/context

ADDENDUM: please consider that valid static contexts are between 2 and 49151 ( daniel_hozac on IRC ) otherwise you will end up with unexplainable error "ncontext: vc_net_migrate(): No such process" when trying to start the vserver.

daniel_hozac&Beuc

Simple ;) See the answer above.

gcc

The scheduler 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