Setting up VServers on Debian

By , last updated .

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.

Terminology

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.

VServer Host Setup

Kernel

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.

Networking

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.

File System

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.

VServer Client Setup

Creating the First Client

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.

Creating More Clients

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

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

Client Maintenance

Listing Running Clients

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

Transfering Data

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.

Secure Shell Access

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.

Hardware Access

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/

Special Topics

Isolating Skype inside a VServer

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:

  1. Create a new client. Until there is a 64 bit Linux version of Skype available, we have to use the --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.

  2. Create a user account inside the client (e.g. during initial setup) and add this user to the audio group: 
    adduser voss audio

    Allow client access to your sound devices as described above.

  3. Download Skype for Linux from the Skype Download Page and install it. There is a Debian package available. I had to install the packages libasound2 and libqt4-gui before I could install Skype.

References