We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

Some programs do things that might work on a normal host but not inside a V-Server. This is often not a fault of V-Server itself, the programs are doing automagic things which fail and no proper error handling is done. Also sometimes the actions need special rights which are not permitted by default in V-Servers. Allowing CAPs is often not necessary since those special CAPs are only required once (e.g. when the program initializes the directories/settings/whatever).

If your V-Server doesn't have access to localhost, then the connection to the OpenGroupware server will fail with a "Internal Server Error".
The apache module for OpenGroupware called mod_ngobjweb uses a hardcoded "127.0.0.1" IP address in the source (handler.c line 339), this line you need to change to the IP address that should be used (the IP of the V-Server that runs the OpenGroupware? server)
If you want to run hylafax in a V-Server, you will get a CAP and device problem which can be easily solved. First you need your capi20 devices in your V-Server, which can't be created by ./MAKEDEV (requires special CAPs) so copy the devices into the V-Server, like this (command run on the host):
cp -aR /dev/capi* /vservers/your_vserver/dev
Now hylafax can access your CAPI ISDN card but will exit after a few seconds, the problem is it tries to create a /dev/null nod in the hylafax chroot. This fails because of missing CAPs, so lets help hylafax again with copying the nod into the hylafax chroot in the V-Server. Like this (command run on the host):
cp -aR /dev/null /vservers/your_vserver/var/spool/hylafax/dev
Allright, now hylafax should have CAPI access and run properly.
Don't know why, but links crashes systematically being inside a screen session inside a V-Server started outside a V-Server. (please elaborate!)
slapd needs name resolution available in order to start up, otherwise it appears to hang. Make sure you have working DNS (or whatever) available to your vserver before starting one with slapd. This behavior is confirmed in my setup, no confirmation from others yet. My Setup: vservers all bind to an interface on a DMZ-like network segment, BIND runs on a vserver. slapd would hang at startup if the BIND vserver had not been started first.
Bind's rndc has a hardcoded 127.0.0.1 somewhere so any command to rndc will fail with connection refused.
You should have a reachable localhost address defined in /etc/hosts and then you can use rndc -s localhost command
Since some version of Asterisk (at least since 1.0.2), it will not run anymore. On start it fails with: "Unable to set high priority"
This can be solved by allowing CAP_SYS_NICE for that V-Server
Fails because of writing to /proc (requires patch)
TODO: write me
Oplocks don't work as smbd insists on receiving break requests from 127.0.0.1
Tested version 1.1.21-0.rc1.7mdk, on Mandrake. With a correct "cupsd.conf file", it works: 
LogLevel info
TempDir /var/spool/cups/tmp
Listen vserver_hostname   # IMPORTANT ! : Do _not_ specify a port here (No "vserver_hostname:631" !)
Port 631
BrowseAddress @LOCAL
BrowseDeny All
BrowseAllow @LOCAL
BrowseOrder deny,allow
<Location />
  Order Deny,Allow
  Deny From All
  Allow From @LOCAL
</Location>
<Location /admin>
  AuthType Basic
  AuthClass System
  Order Deny,Allow
  Deny From All
  Allow From YOUR_NETWORK_ADDRESS/YOUR_NETMASK # Example: 172.16.0.0/24
</Location>
This will make Cupsd start, but more tweaking on the ACLs may be necessary to avoid authentification problems... I'll update this section when I fully have this working.