Virtualization With Xen On Debian Lenny (AMD64)

Version 1.0
Author: Falko Timme

This tutorial provides step-by-step instructions on how to install Xen on a Debian Lenny (5.0) system (AMD64).

Xen lets you create guest operating systems (*nix operating systems like Linux and FreeBSD), so called "virtual machines" or domUs, under a host operating system (dom0). Using Xen you can separate your applications into different virtual machines that are totally independent from each other (e.g. a virtual machine for a mail server, a virtual machine for a high-traffic web site, another virtual machine that serves your customers' web sites, a virtual machine for DNS, etc.), but still use the same hardware. This saves money, and what is even more important, it's more secure. If the virtual machine of your DNS server gets hacked, it has no effect on your other virtual machines. Plus, you can move virtual machines from one Xen server to the next one.

I do not issue any guarantee that this will work for you!


1 Preliminary Note

I'm using a Debian Lenny system (x86_64) with the hostname and the IP address as the host system (dom0). (The setup might differ slightly if you are on an i386 system.) I will use Debian Lenny for the virtual machines (domU) as well.

This guide will explain how to set up image-based virtual machines and also LVM-based virtual machines.


2 Installing Xen

To install Xen, we simply run

apt-get install xen-hypervisor-3.2-1-amd64 xen-linux-system-2.6.26-1-xen-amd64 xen-utils-3.2-1 xenstore-utils xenwatch xen-shell xen-tools 

Afterwards we open /etc/modules and make sure that we have the line loop max_loop=64 in it (this step is needed only if you want to create image-based virtual machines - you can skip it if you want to create LVM-based virtual machines):

vi /etc/modules
loop max_loop=64

Next we open /etc/xen/xend-config.sxp...

vi /etc/xen/xend-config.sxp

... and uncomment the line (network-script network-bridge) and comment out the line (network-script network-dummy). Also make sure that the line (vif-script vif-bridge) is enabled:

(network-script network-bridge)
#(network-script network-dummy)
(vif-script vif-bridge)

Then reboot the system:



uname -r

and your new Xen kernel should show up:

server1:~# uname -r


3 Creating Image-Based Virtual Machines

We will use xen-tools to create virtual machines. xen-tools make it very easy to create virtual machines - please read this tutorial to learn more: We've already installed xen-tools in the previous step (chapter 2).

Now we edit /etc/xen-tools/xen-tools.conf. This file contains the default values that are used by the xen-create-image script unless you specify other values on the command line. I changed the following values and left the rest untouched:

vi /etc/xen-tools/xen-tools.conf
dir = /home/xen
dist   = lenny     # Default distribution to install.
gateway   =
netmask   =
broadcast =
passwd = 1
kernel      = /boot/vmlinuz-`uname -r`
initrd      = /boot/initrd.img-`uname -r`
mirror =
serial_device = hvc0
disk_device = xvda

The dir line specifies where the virtual machine images will be stored. dist specifies the distribution to be installed in the virtual machines (Debian Lenny) (there's a comment in the file that explains what distributions are currently supported).

The passwd = 1 line makes that you can specify a root password when you create a new guest domain. In the mirror line specify a Debian mirror close to you.

Make sure you specify a gateway, netmask, and broadcast address. If you don't, and you don't specify a gateway and netmask on the command line when using xen-create-image, your guest domains won't have networking even if you specified an IP address!

It is very important that you add the line serial_device = hvc0 because otherwise your virtual machines might not boot properly!

Before we go on, we must create the directory where the virtual machine images should be stored:

mkdir /home/xen 

Now let's create our first guest domain,, with the IP address

xen-create-image --size=4Gb --swap=256Mb --ip= --memory=128Mb --arch=amd64 --role=udev 

Options that you specify on the command line override the settings in /etc/xen-tools/xen-tools.conf. Options that are not specified on the command line are taken from /etc/xen-tools/xen-tools.conf. Please make sure that you add --role=udev, or your virtual machine might not boot properly!

(To learn more about the available options, take a look at the xen-create-image man page:

man xen-create-image


The xen-create-image command will now create the virtual machine for us. This can take a few minutes. The output should be similar to this one:

server1:~# xen-create-image --size=4Gb --swap=256Mb --ip= --memory=128Mb --arch=amd64 --role=udev

General Information
Hostname       :
Distribution   :  lenny
Partitions     :  swap            256Mb (swap)
                  /               4Gb   (ext3)
Image type     :  sparse
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-2.6.26-1-xen-amd64
Initrd path    :  /boot/initrd.img-2.6.26-1-xen-amd64

Networking Information
IP Address 1   : [MAC: 00:16:3E:D0:91:EE]
Netmask        :
Broadcast      :
Gateway        :

Creating partition image: /home/xen/domains/

Creating swap on /home/xen/domains/

Creating partition image: /home/xen/domains/

Creating ext3 filesystem on /home/xen/domains/
Installation method: debootstrap

Running hooks

Role: udev
        File: /etc/xen-tools/role.d/udev
Role script completed.

Creating Xen configuration file
Setting up root password
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
All done

Logfile produced at:

There should now be a configuration file - /etc/xen/ Take a look at it to become familiar with virtual machines configuration files:

vi /etc/xen/
# Configuration file for the Xen instance, created
# by xen-tools 3.9 on Tue Feb  3 17:56:25 2009.
#  Kernel + memory size
kernel      = '/boot/vmlinuz-2.6.26-1-xen-amd64'
ramdisk     = '/boot/initrd.img-2.6.26-1-xen-amd64'
memory      = '128'
#  Disk device(s).
root        = '/dev/xvda2 ro'
disk        = [
#  Hostname
name        = ''
#  Networking
vif         = [ 'ip=,mac=00:16:3E:D0:91:EE' ]
#  Behaviour
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

(Please note: if you have a dual-core or quad-core CPU and want the virtual machine to use all CPU cores, please add the line vcpus = '2' or vcpus = '4' to the configuration file.)

To start the virtual machine, run

xm create /etc/xen/


xm console

to log in on that virtual machine (type CTRL+] if you are at the console, or CTRL+5 if you're using PuTTY to go back to dom0), or use an SSH client to connect to it (

To get a list of running virtual machines, type

xm list 

The output should look like this:

server1:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  3488     2     r-----    398.2                             6   128     1     -b----      2.8

To shut down, do this:

xm shutdown 

If you want to start automatically at the next boot of the system, then do this:

ln -s /etc/xen/ /etc/xen/auto

Here are the most important Xen commands:

xm create -c /path/to/config - Start a virtual machine.
xm shutdown <name> - Stop a virtual machine.
xm destroy <name> - Stop a virtual machine immediately without shutting it down. It's as if you switch off the power button.
xm list - List all running systems.
xm console <name> - Log in on a virtual machine.
xm help - List of all commands.

A list of all virtual machines that were created with the xen-create-image command is available under


server1:~# xen-list-images
Memory: 128

To learn more about what you can do with xen-tools, take a look at this tutorial:

Share this page:

Suggested articles

6 Comment(s)

Add comment


By: Ian

Hi Falko,

Thanks for the howto. Sadly I did not get past the reboot in stage 2 

The minor problem was  that I have my boot partition on RAID-1, which confuses GRUB, so I had to edit (hd1,0) into (hd0.0) to get it to boot at all.

The more serious problem is that the new kernel cannot load the NVIDIA drivers for my graphics card. And in trying to purge the old drivers and install again, I have got myself into the situation where none of the kernels will load X, the driver install script demands gcc-4.1 which is installed, but it can't find it.

I rather suspect a complete reformat and reinstall is coming on



By: WillyFoG

Hi Ian!

 The problem you had with the nvidia driver is very common, and very easy to solve.

The only thing you have to do is a symbolic link from gcc to gcc-4.1. By default this link points to gcc-4.3, if I'm not in a mistake.




By: Anonymous

nice article!

It would be nice to see one specific to the intel architecture too!

Also, if you have an example of  moving an image to another machine -


By: x-point

just a note: the architecture is called amd64, but it also run on intel 64 bit-enabled processors....

By: Boris

I believe there should a way to backport Xen 3.3.X Hypervisor to Debian Lenny. Something similar backport Intrepid Xen 3.3 Hypervisor to Ubuntu Hardy Dom0.

By: skug67

OK, so maybe I'm getting greedy, but the easiest way for me to keep everything up-to-date in my DomU's is to use pygrub and let the kernel get automatically updated there, rather than having to update the kernel reference in the xen configuration file.  But when the DomU is jaunty (which doesn't provide a xen-compatible kernel), that means a mixed system which seems to be giving poor apt-get fits.  I've been able to get to a stable situation where the only packages actually sourced from Debian are the kernel and kernel module files.  And I've set up pinning in /etc/apt/preferences so that only the kernel and module files can come from Debian.   But nevertheless when I add the Debian repositories back into /etc/apt/sources.list.d it seems to think that anything appearing in both Debian and Ubuntu repositories has come from the Debian repos, so that it tries to update them to get them sourced from Ubuntu.  And it will try to do this endlessly.

 Obviously, I can solve this problem by enabling the Debian repos only long enough to check for kernel updates and then disabling them again.  But it seems like there should be a better solution.  Any thoughts?


 Seth Green