A few weeks back, I installed a vanilla Debian Wheezy on an OVH’s Kimsufi. OVH is a large web hosting company that provides dedicated servers called Kimsufis. This explains how to proceed using debootstrap and then setting up Xen for virtualization.


These are some preliminary examinations, you can jump straight to the (Re)install part to get your hands dirty.

Installation strategy

There are some ways I’ve thought to install Debian Wheezy on a Kimsufi:

  • via the manager (“Wheezy ALPHA” being available now): I’m not sure if we can make our very own custom partitioning keeping some existing data. Moreover, your distro will be tainted with OVH’s stuff like RTM and their SSH keys. → Nah.

  • via qemu: the plan would be to download the latest Wheezy ISO and boot it on qemu with VNC enabled. But this would install Debian over emulated hardware which is no good. → Messy.

  • via rescue mode: OVH provides what they call a “rescue mode” which boots on a live CD giving you access to your server hard drive. So the plan is to debootstrap to /dev/sda, set up minimal functioning network and sshd then reboot on the real system. → Sounds good to me :).

Custom kernel

Why and why not using a custom kernel.

  • why
    • Does Debian’s stock kernel support OVH hardware? Probably. Is it optimized for their hardware? Unlikely.
    • Debian’s kernel includes a lots of exotic hardware support – both as m (module) or y (included)
    • OVH’s kernel disables all useless stuff like Bluetooth, WiFi, touchscreen and so on
  • why not
    • What about kernel updates?

OVH’s kernels are static, i.e. no modprobe.

Why no PV

Paravirtualization drawbacks:

  • Requires Wheezy (Linux >= 3) or patched kernel – current Lenny VMs must be upgraded.
  • Sharing kernels on the dom0 is annoying.
  • 2-partition scheme seems to be mandatory? Does it work with block partitions like /dev/sdaNN?
  • HVM full isolation is better since it gives total freedom to guests who want to run BSD, etc.



If you’ve got existing data, backup them all before going any further – just in case.

You can use OVH’s FTP if 100 Gio is enough for you or use rsync to backup things locally.


If you have running VMs (“domU” in Xen wording), don’t forget to shut them gracefully with xm shutdown <ID>.

Then enable the “rescue mode” in the manager and reboot your server.

Once you got the prompt on the live CD, you can start the fresh install. Here are the steps I used but YMMV :).

$ mkfs.ext3 /dev/sda1
$ mkfs.ext4 /dev/sda2

$ mount /dev/sda2 /mnt
$ mkdir /mnt/boot
$ mount /dev/sda1 /mnt/boot

$ debootstrap --verbose --arch amd64 --variant minbase --include dialog,vim,resolvconf,ifupdown,netbase,net-tools,ssh wheezy /mnt https://mir1.ovh.net/debian

$ cat > /mnt/etc/fstab <<CONF
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/sda1   /boot   ext3    errors=remount-ro   0   1
/dev/sda2   /       ext4    errors=remount-ro   0   1
/dev/sda3   swap    swap    defaults            0   0
/dev/sda5   /srv    ext3    errors=remount-ro   0   1
proc        /proc   proc    defaults            0   0
sysfs       /sys    sysfs   defaults            0   0

$ cat > /mnt/etc/network/interfaces <<CONF
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
  address 188.165.X.Y
  gateway 188.165.X.254

# FIXME: IPv6 support

$ cat > /mnt/etc/hosts <<CONF localhost.localdomain localhost
188.165.X.Y ks123456.kimsufi.com ks123456

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

$ echo 'ks123456' > /mnt/etc/hostname

$ cat > /mnt/etc/apt/sources.list <<CONF
deb https://mir1.ovh.net/debian wheezy main

deb https://security.debian.org/ wheezy/updates main

$ vim /mnt/etc/ssh/sshd_config # `PermitRootLogin yes` should be there

$ echo "root:super_password" | chroot /mnt chpasswd

$ mount --rbind /dev /mnt/dev

$ LANG=C chroot /mnt /bin/bash

# from inside chroot

$ mount -a

$ dpkg-reconfigure tzdata # 13 (Etc) then 33 (UTC)

$ apt-get update
$ apt-cache search linux-image
$ apt-get install linux-image

$ apt-get install grub
$ grub-install --no-floppy --recheck /dev/sda
$ update-grub
$ ls /boot/grub/grub.cfg # should be happy

Finally! Now disable the “rescue mode” then reboot. If you’re stuck with Grub rescue prompt (it happened to me on a test machine but not the actual Kimsufi), type in configfile /boot/grub/grub.cfg and reinstall Grub once booted.


Install the hypervisor and tools

To get Xen support, simply install those three packages (xen-hypervisor provides /boot/xen-4.1-amd64.gz):

apt-get install xen-hypervisor xen-tools xen-utils

Prioritize Xen

Prioritize the Xen kernel over native (more info):

dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen


Select the xl toolstack

Xen toolstacks, in short:

  • Old toolstack: xm based on xend
  • New one: xl based on libxl
  • New bloated one: xe based on xapi

You may want to look at this comparison.

Why xl and not xe?

xe/xapi seemed neat, especially the RRD bit which provides nice graphs about your VMs. But xapi requires openvswitch. When I tried to install it, apt-get was stuck in an infinite loop because of a missing kernel module :/. Besides, openvswitch helps with things like QoSiptableslimit module already does that.

It bloats your distro because it launches at least three more daemons, needs custom kernel modules, relies on some experimental Java stuff. All that to provide things like QoS that I either can do using iptables or that I don’t need.

Apparently, you can tell xapi to use Linux bridging capability instead of OVS but it doesn’t work either for me since I’ll need to use routing and not bridging to set up the network. ebtables is fine but it’s not as powerful as iptables to do amazing things and fine-tuning (see below).

And for the graphs, I guess it’s possible to retrieve data from xl and send it through Munin to get some nice graphs…

“xl is very lightweight and is a great choice for developers or users who are most comfortable with Unix like CLI tools.” – Choice of Toolstacks

Here we go! One thing though: Python support has been dropped from xm – annoying but not a big deal.

How to set the toolstack

Edit /etc/default/xen and set TOOLSTACK=xl then reboot. xend will not start any more (see /etc/init.d/xen for more info).

dom0 important tweaking

Disable Xen ballooning & set dom0 dedicated RAM

Use free -m to see how much RAM you’re using and set a fair amount of dedicated memory by adding the two lines into /etc/default/grub:

# Xen boot parameters for all Xen boots

After reboot, you may blurt out a little “dafuq” seeing this:

  • free -m reports 176M
  • xl list 0 reports 256M

This is fine – well, sort of – the missing memory seems to be marked as “reserved” according to /var/log/dmesg.

Then disable auto ballooning in /etc/xen/xl.conf:


And in /etc/xen/xend-config.sxp:

(dom0-min-mem 256)
(enable-dom0-ballooning no)

Disable domU save/restore

Unless you have room to save VMs states, disable it in /etc/default/xendomains:


Enough CPU time

Add these two lines into /etc/rc.local (more info):

# Give dom0 two times more CPU time than guests
xl sched-credit -d Domain-0 -w 512

Xen is now all set up, you need to update-grub then reboot to apply all the changes!

domU config

Here is a example config file to get you started with a HVM guest:

hostname = "test"
kernel = "hvmloader"
device_model = "qemu-dm"
builder = "hvm"
boot = "c"
memory = "1024"
vcpus = "2"
disk = ["phy:/dev/sda6,xvda,w"]
pae = "1"
apic = "1"
on_poweroff = "destroy"
on_crash = "restart"
on_reboot = "restart"


What about VMs’ networking? This will be discussed in another post – how to set up a routed network with Xen 4 using a dual-stack IPv4 and IPv6.