For installing Dom0 on etch you have to do a regular install, while keeping the following in mind and doing the extra stuff at the end.

Considerations: diskspace and RAM

The only things influencing the installation through d-i of the xen environment are diskspace and RAM. To start with the last: usually 196 MB RAM is needed for domain0. You can do with less: 128MB and I've even seen reports from people running with 64MB or even 32MB, but keep to defaults if this is your first time with xen. Aditional functionality for domain0 like dhcpd, iptables and installation services (eg. apache with apt-proxy) claim more. For a default domain0 you need 512MB diskspace and then you've got to keep an eye on it, so do at least 1GB. I use 2GB to be safe. For simplicities sake I keep it all in 1 filesystem. Local requirements for logging, accounting and/or auditing may claim extra. Swap space is the usual rule of thumb: RAM * attention. General methods for storing your user-domains file data are, in the order of preference: external san/nfs, local lvm2, local partitions, local files.


Theses installation notes are focusing on installing Xen during Debian installation (i.e under D-I). Some general notes for Installation Xen can be fount in the ["Xen"] page.

Do a regular install and select a standard kernel. Use grub for the bootloader (xen is not compatible with lilo) and choose mkinitramfs-tools for the ramdisk creator (which is default). Continue right up to the menu option "Finish the installation" but stop there (don't select it). Switch to the second console with 'Ctrl-Alt-F2' and hit enter.

If you don't already know, you can check if your cpu has hardware virtualisation [the "vmx" flag for Intel or the "svm" flag for AMD]


Chroot into your target install with

Optionnaly, you can enable "command line completion" to complete package using "tab" key :

You need to install a few package that pulls most of the dependencies (xen-ioemu is only needed by CPU with virtualisation hardware) :

Warning: (as of 2006-10, might be an obsolete warning) : if you are useing a separate filesystem for /boot like I do, your /boot/grub/menu.lst bootloader configuration file doesn't get modified correctly. In this case every path needs to read /<filename>, but for some bug the one for xen.gz doesn't but looks like '/boot/xen.gz', so change it to '/xen.gz'.

Since we have the opportunity, adjust your xen config file /etc/xen/xend-config.sxp (save the original for later study). The following works on a system with a single nic:

Exit your chroot

and change back to your installation screen with 'Ctrl-Alt-F1' and select "Finish the installation".

If the system does not boot, try adding a 'noacpi' option to the vmlinux line in menu.lst first.

Ref: (dd. 20070930) en-unstable.


The easiest way to get this done is to use xen-tools (and, if this doesn' do what you need, Steve Kemp is keen and fast in impementing useful suggestions).

The next well tested and working way is to create a domU filesystem from a dom0 by following ["Installing Debian GNU/Linux from a Unix/Linux System"]; ; - and adding some tweaks which are necessary to get a Xen guest run properly - mainly adjusting inittab and installing libc6-xen, and maybe the kernel modules needed by the kernel you want to run for the domU.

A not very well tested, but for some users and use cases more appropriate option is trying to run D-I inside a DomU, which is described below. This is also the preferred method some other distributions offer their users - fedora/redhat runs anaconda in a domU, suse runs yast inside a domU. If this is fully working, users have (nearly?!) not differences between installing a real hardware system or a virtualized one.

You can start d-i in DomU by creating a DomU config file with the xen DomU kernel and the initrd from the netboot images ( and granting the DomU (or user-domain) read/write acces to some empty pre-created filesystems you want to use in it since you definitely do not want to give the DomU access to your mbr. You need to copy the DomU kernel's /lib/modules/<version> to the initrd.

It works, I did this some months ago with the 3.0.1 xen version from, but am unable to reproduce due to the current state of the xen software on etch and Waiting for, I suppose :-(

(mm) I've tried following this path, as I find myself annoyed at the limitations of xen-tools and the amount of manual setup debootstrap leaves. It seems to be usable with the released Etch Xen. There are some rough spots - keyboard config fails (left it unchanged), no kernel modules were found... Partitioning is a bit of a surprise, though. The trick seems to be to format all the partitions (I'm using LVM and testing with /dev/sda1 and /dev/sda2 as disk and swap), otherwise the partitioner will insist on creating partition tables for them. Didn't experiment to see how that would work out as I really didn't want partitioned partitions! Other problems (some of which I could have avoided):


/!\ Work in progress, your help is appreciated

DomU graphical

I guess it must be possible to do this, maybe in a similar way as the DomU, through the xen native vnc support or in a straight X11 session over a network connection with the ssh console option (does the graphical installer have X11 client support?).

To boot a domU with graphical (VNC) access use the following options :

and then

/!\ Work in progress, your help is appreciated

Using HVM (VT processors)

Make sure you have the "xen-ioemu" package installed

Sample config file :