By Jochen Voss, last updated 2011-09-22
This page explains how to use Linux-VServer to run several virtual machines inside a physical machine. A short overview over VServer can be found on the Wikipedia VServer page.
In this text I will use the word host to refer to the physical machine the VServer setup is running on. I will use the word client to refer to the virtual machines running on this host.
To use VServer on Debian you will need a kernel with VServer support
patched in on the host. If you are using precompiled kernel images, you
need one with the string vserver in the package name. On my
amd64 system I could use linux-image-2.6-vserver-amd64. User
space support is contained in the two packages util-vserver
and vserver-debiantools.
On the host, first assign a network segment to the VServer setup. I create a dummy device for this purpose. On a Debian system this can be done by adding a sniplet like the following to /etc/network/interfaces:
auto dummy0
iface dummy0 inet static
address 10.1.1.1
netmask 255.255.255.0
If everything worked, we should now be able to see the assigned address on the interface:
automatix:/# ip addr show dev dummy0
5: dummy0: <BROADCAST,NOARP,UP,10000> mtu 1500 qdisc noqueue
link/ether 6e:07:f6:a2:7d:d1 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global dummy0
inet6 fe80::6c07:f6ff:fea2:7dd1/64 scope link
valid_lft forever preferred_lft forever
Network packets sent from the clients will appear to come from this interface. Thus, to give outside network connectivity to the clients, we need to set up forwarding and msquerading for this interface:
echo 1 >/proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 10.1.1.1/24 -j SNAT --to-source $IP
where $IP stands for the IP address of your external
interface. Note that this has to be done after every reboot of the host.
Probably it is best to put these commands in one of the system startup
files.
Before starting to create clients, you have to decide where the client file systems will live. By default, each client's file system will be stored in a sub-directory of /var/lib/vservers/ on the host. Since these sub-directories may grow very big and since you might want to include some client data into backups etc., this location is probably not optimal. You can change the location of vserver root directories by adjusting the /etc/vservers/.defaults/vdirbase symlink.
The first client is special. We set it up using the following command:
newvserver --hostname test1 --domain example.com \ --ip 10.1.1.2/24 --interface dummy0 --dist etch vserver start test1 vserver enter test1
Make sure that networking is working inside this client and that a sane set of packages is installed.
Hint. On my system, the setup script got the nameserver information wrong. This led to long delays while the queries to the first, invalid server timed out. Removing the invalid entry from the client's /etc/resolv.conf fixed the problem.
Once one client is set up, we can generate more VServers by just copying this one:
dupvserver --from test1 --to test2 --ip 10.1.1.3
I had to manually change the security context of the new client by editing the file /etc/vservers/test2/context. Before the change I got the error message
automatix:~# vserver test2 start vcontext: vc_ctx_create(): File exists An error occured while executing the vserver startup sequence; when there are no other messages, it is very likely that the init-script (/etc/init.d/rc 3) failed. Common causes are: * /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the 'apt-rpm' build method knows how to deal with this, but on existing installations, appending 'true' to this file will help. Failed to start vserver 'test2'
After I changed the number in the file /etc/vservers/test2/context from 40001 to 40002 everything started working. I have no idea whether this is some very obvious bug or whether I did something wrong.
Removing clients is easy:
automatix:~# vserver test2 stop Stopping periodic command scheduler: crond. Stopping internet superserver: inetd. Stopping system log daemon: syslogd. Asking all remaining processes to terminate...done. Killing all remaining processes...done. automatix:~# vserver test2 delete Are you sure you want to delete the vserver test2 (y/N) y
automatix:~# vserver-stat CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 40001 2 14.8M 1.4M 0m00s32 0m00s16 9m06s29 test1 40003 2 14.8M 1.4M 0m00s24 0m00s24 9m03s32 test3
The easiest way to get some data in or out of one of the clients, is to directly access the client file system from the outside (i.e. on the host). By default the client filesystems are located under /var/lib/vservers/. Data which is copied in there appears immediately on the client.
Basic access to the client can be obtained using the command
vserver test1 enter. But to run X11 applications inside the
client or to get remote access it is useful to have an ssh daemon running
inside the client. For this you need to install the package
openssh-server on the client.
Hints.
ListenAddress in the sshd config file
on the host to avoid this.
X11UseLocalhost no
in the sshd_config file on the client to allow X11 forwarding to work.
You can allow client access to your hardware by simply creating the corresponding device files in the client file system hierarchy. For example to give a client permission to access the sound hardware on the system, you can just copy the ALSA device files:
rsync -av /dev/snd /var/lib/vservers/test1/dev/
You might want to create a dedicated VServer client for running Skype. This allows you to easily run the i386 Skype binary on an amd64 machine, and also it allows to contain the binary only, unreviewable Skype executable in a restricted environment.
The idea is to run skype inside the client. We will connect to the
client using ssh -X so that Skype can use the X-server
running on the host. The client will get access to the audio devices, so
that Skype can access the sound hardware without help.
Steps I needed to perform in order to make this work:
--arch=i386 option:
newvserver --hostname skype --domain example.com \ --ip 10.1.1.101/24 --interface dummy0 --dist etch --arch i386
Install and configure the ssh daemon inside the client.
audio group:
adduser voss audio
Allow client access to your sound devices as described above.
libasound2 and libqt4-gui before I
could install Skype.
Copyright © 2011 Jochen Voss. All content on this website (including text, pictures, and any other original works), unless otherwise noted, is licensed under the CC BY-SA 4.0 license.