Differences between revisions 1 and 205 (spanning 204 versions)
Revision 1 as of 2005-11-26 22:54:20
Size: 1551
Editor: PeMac
Comment:
Revision 205 as of 2012-05-28 13:08:51
Size: 27019
Editor: ?IanCampbell
Comment: Pull Debian installer info under domU installation section
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#languages en
||<tablewidth="100%"style="border: 0px hidden ;">~-Translation(s): [[id/Xen|Indonesian]] -~ ||<style="border: 0px hidden ; text-align: right;"> (!) [[/Discussion]] ||
----
 . <<TableOfContents(2)>>
= Xen Overview =
Line 3: Line 8:
Xen is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Xen is Open Source software, released under the terms of the GNU General Public License. We have a fully functional ports of Linux 2.4 and 2.6 running over Xen, and regularly use it for running demanding applications like MySQL, Apache and PostgreSQL. Any Linux distribution (RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS.

In addition to Linux, members of Xen's user community have contributed or are working on ports to other operating systems such as NetBSD (Christian Limpach), FreeBSD (Kip Macy) and Plan 9 (Ron Minnich).


 * http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
'''Xen''' is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Xen is Open Source software, released under the terms of the GNU General Public License. We have a fully functional ports of Linux 2.6 running over Xen, and regularly use it for running demanding applications like MySQL, Apache and PostgreSQL. Any Linux distribution (!RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS.

In addition to Linux, members of Xen's user community have contributed or are working on ports to other operating systems such as NetBSD (Christian Limpach), FreeBSD (Kip Macy) and Plan 9 (Ron Minnich).

== Different types of virtualization offered by Xen ==

There are two different types of virtualization offered by Xen:
 * Para-virtulization and
 * Hardware-supported virtualization

=== Para-virtualization ===
A term used to describe a virtualization technique that allows the operating system to be aware
that it is running on a hypervisor instead of base hardware. The operating system must be
modified to accommodate the unique situation of running on a hypervisor instead of basic
hardware.

=== Hardware Virtual Machine ===
A term used to describe an operating system that is running in a virtualized environment unchanged and unaware that it is not running directly on the hardware. Special hardware is required to allow this, thus the term HVM.

(Source: What is Xen Hypervisor, [[http://www.xen.org|www.xen.org]])

= Domain 0 (Host) Installation =

The Xen and debootstrap software in Squeeze (Debian 6.0) are very much newer than that in Lenny. Because of that, working with Xen becomes a lot easier.

The setup described here is tested for Debian Lenny and Ubuntu Maverick virtual machines, but should work for a lot more.

First install the hypervisor, xen kernel and xen-tools. This can be done by a metapackage:

{{{
aptitude -P install xen-linux-system
}}}

To get Xen HVM support [[http://wiki.xen.org/wiki/Main_Page|Xen 4.0 Wiki]]
{{{
apt-get install xen-qemu-dm-4.0
}}}

Debian Squeeze uses Grub 2 whose default is to list normal kernels first, and only then list the Xen hypervisor and its kernels.

You can change the default kernel to boot in two ways:

 * Change the priority of GRUB's Xen configuration script ({{{20_linux_xen}}}) to be higher than the standard Linux config ({{{10_linux}}}):

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

to undo this:

{{{
dpkg-divert --rename --remove /etc/grub.d/20_linux_xen
}}}

 * Modify the value of GRUB_DEFAULT in the file /etc/default/grub. The value is an integer starting at 0 representing the order of the menuentry item to boot. You can see a list of all menuentry values in order by typing

{{{
grep menuentry /boot/grub/grub.cfg
}}}

Count to the number of the first Xen kernel, starting at 0, and enter it in the default file. Note that this procedure is not robust against the installation or removal of new kernel versions which will cause the Xen entries to get different numbers, for this reason reordering the priorities using {{{dpkg-divert}}} as above is preferable.

After either of these procedures, do an update to the GRUB configuration:

{{{
update-grub
}}}

If you wish to improve this process there is an open bug discussing the default values after a Xen installation. [[DebianBug:603832|#603832]]

To avoid getting boot entries for each virtual machine you install on a volume group, disable the GRUB OS prober.

/!\ ToDo: does this problem still happen and under what circumstances? Bug number?

Note that if you are running a computer with multi-boot with for example Windows, this will also remove the entries for it, which might not be what you wish for.

Edit /etc/default/grub and add:
{{{
# Disable OS prober to prevent virtual machines on logical volumes from appearing in the boot menu.
GRUB_DISABLE_OS_PROBER=true
}}}

You may also want to pass some boot parameters to Xen when starting up in normal or recovery mode. Add these variables to /etc/default/grub to achieve this:
{{{
# Xen boot parameters for all Xen boots
GRUB_CMDLINE_XEN="something"
# Xen boot parameters for non-recovery Xen boots (in addition to GRUB_CMDLINE_XEN)
GRUB_CMDLINE_XEN_DEFAULT="something else"
}}}

After editing GRUB configuration, you must apply it by running:
{{{
update-grub
}}}

By default, when Xen dom0 shuts down or reboots, it tries to save the state of the domUs. Sometimes there are problems with that - it could fail because of a lack of disk space in /var, or because of random software bugs. Because it is also clean to just have the VMs shutdown upon host shutdown, if you want you can make sure they get shut down normally by setting these parameters in /etc/default/xendomains:

{{{
XENDOMAINS_RESTORE=false
XENDOMAINS_SAVE=""
}}}

It is recommended that you manage your own network bridge using the [[BridgeNetworkConnections| Debian network bridge]]. The Xen supplied network scripts are not always reliable and will be removed from a later version.

Should you still wish to use them, in /etc/xen/xend-config.sxp enable the network bridge by commenting out the line that was already there for that. (You may check [[http://wiki.xensource.com/xenwiki/XenNetworking| XenNetworking]] page in Xen wiki.)

{{{
(network-script 'network-bridge antispoof=yes')
}}}

The antispoof=yes will activate Xen firewall to prevent that one of your VM uses an IP that it is not allowed to use (for example, if a domU was to use the gateway as its IP, it could seriously break your network, this will prevent it). In this case, you will need to specify the IP of your domU in the vif statement of your domUs.

If you get "missing vif-script, or network-script, in the Xen configuration file", try adding executable permission in:
{{{
chmod +x /etc/xen/scripts/*}}}

This config file also has options to set the memory and CPU usage for your dom0, which you might want to change.
To reduce dom0 memory usage as it boots, use the dom0_mem kernel option in the aforementioned GRUB_CMDLINE_XEN variable. Xen wiki also advise to disable dom0 memory ballooning and set minimal memory in /etc/xen/xend-config.sxp (1024M is an example) :

{{{
(dom0-min-mem 1024)
(enable-dom0-ballooning no)
}}}

=== Serial console access ===

To get output from GRUB, the Xen hypervisor, the kernel and getty (login prompt) via ''both'' VGA and serial console to work, here's an example of the right settings on squeeze:

Edit {{{/etc/default/grub}}} and add:

{{{
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1"
GRUB_TERMINAL="console serial"
GRUB_TIMEOUT=5
GRUB_CMDLINE_XEN="com1=9600,8n1 console=com1,vga"
GRUB_CMDLINE_LINUX="console=tty0 console=hvc0"
}}}

Here's what I used to configure the serial console (for a Supermicro X8STi-F motherboard with IPMI and SOL):

{{{
GRUB_CMDLINE_XEN="loglvl=all guest_loglvl=all com1=115200,8n1,0x3e8,5 console=com1,vga"
GRUB_CMDLINE_LINUX="console=hvc0 earlyprintk=xen"
}}}

In {{{/etc/inittab}}} you need at least these lines:

{{{
1:2345:respawn:/sbin/getty 38400 hvc0
2:23:respawn:/sbin/getty 38400 tty1
# NO getty on ttyS0!
}}}

This way, tty1 will show up at the VGA output, and the hvc0 will show up at the serial console.

To keep both Xen and dom0 kernel output on the same tty, just omit the "vga"-related settings from the above setup.

If you need to debug Xen and see a crash dump of the kernel, you can do it using IPMITool if your server has SOL:

ipmitool -I lanplus -H server-ip-address -U your-username sol activate | tee my-log-file.txt

= Installation as a DomU (guest) =

== Using xen-tools ==

DebianPkg:xen-tools is a set of scripts which can easily create fully configured Xen guest domains.

Once you have installed dom0 you can install on your host with:

{{{
apt-get install xen-tools
}}}

Then you can create virtual machines with this command:

{{{
xen-create-image --hostname <hostname> --ip <ip> --vcpus 2 --pygrub --dist <lenny|maverick|whatever>
}}}

To configure xen-tools, you can edit `/etc/xen-tools/xen-tools.conf` which contains default values that the xen-create-image script will use.

Read the xen-create-image manual page for information on the available options.

In case you use xen-tools with ''--role'' be aware of [[DebianBug:588783|#588783]].

These are some real-life examples of params that may need to be changed:

{{{
# Virtual machine disks are created as logical volumes in volume group 'universe' (hint: LVM storage is much faster than file)
lvm = universe
 
size = 50Gb # Disk image size.
memory = 512Mb # Memory size
swap = 2Gb # Swap size
 
# Default gateway and netmask for new VMs
gateway = x.x.x.x
netmask = 255.255.255.0
 
# When creating an image, interactively setup root password
passwd = 1
 
# Let xen-create-image use pygrub, so that the grub from the VM is used, which means you no longer need to store kernels outside the VMs. Keeps things very flexible.
pygrub=1
}}}

=== Possible problems and bugs ===

 * If your domU kernel happens to miss support for the xvda* disk devices (the xen-blkfront driver), use the --scsi option that makes the VM use normal SCSI HD names like sda*. You can also set scsi=1 in /etc/xen-tools/xen-tools.conf to make this the default.

 * Debian Bug [[DebianBug:584152|#584152]] Error during xen-create-image: {{{mkfs.ext3: /lib/libblkid.so.1: version `BLKID_2.17' not found (required by mkfs.ext2)}}}. Solve this by downgrading the mkfs tool.

 * Error starting xend 3.4. Use the 4.x from current squeeze packages. [[http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1620|Xen Bug #1620]]

 * PvGrub exists, but PvGrub is not packaged in squeeze, cf. [[DebianBug:588839]], [[http://wiki.xensource.com/xenwiki/PvGrub|PvGrub on Xen Wiki]]

 * On an Intel Corporation Core Processor Integrated Graphics Controller (rev 02) using the i915 module, X fails. This means if you have GDM or any other display manager installed you will not be able to use your computer after booting into a Xen hypervisor. Disabling GDM is a work around but X.org continues to lock up the keyboard and screen if started manually via startx.

== Using Debian Installer ==

The Xen wiki page [[http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer|Debian Guest Instalation Using DebianInstaller]] contains instructions on how to install Xen DomU from Lenny onwards using [[Debian Installer]].

= Upgrading/transition =

See also: [[http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#xen-upgrades|Debian Release Notes]]

Upgrading a server to Squeeze that uses both Lenny Dom0 and DomU's is fairly straightforward. There are a few catches that one needs to be aware of however: [[http://net153.net/blog/20101217-13-14.html|Reference]]

 * ~+Dom0 Issues+~
  * The Xen packages will not upgrade themselves. They must be manually removed and the latest Xen packages must be installed from the Debian Squeeze repository through apt.
  * pygrub in Xen-4.0 will need to be patched as per [[DebianBug:599243|#599243]]
  * xen.independent_wallclock sysctl setting is not available for newer squeeze kernels supporting pvops. If you have relied on it, you would have to run ntpd in dom0 and domUs. [[http://my.opera.com/marcomarongiu/blog/2011/01/05/independent-wallclock-in-xen-4|source]]

 * ~+DomU Issues+~
  * A Squeeze DomU will not be able to boot on the Xen-3.2 package supplied by Lenny because this older version will not support grub2. A Lenny DomU can be upgraded to Squeeze while running on a Lenny Dom0 but it will not be able to be booted until the Dom0 has been upgraded to the Xen-4.0 packages.
  * The entries added to chain load grub1 to grub2 will not allow pygrub to find the correct partition. Before rebooting a freshly upgraded Squeeze DomU, make sure to rename or remove /boot/grub/menu.lst. This will force pygrub to look for the /boot/grub/grub.cfg file which will be in the correct format.
  * A qcow image created with qcow-create and the BACKING_FILENAME option on Lenny will not be able to boot on Squeeze because the ability to use qcow images as backing files has been removed in Xen versions after 3.2. Also, if you try to boot such an image on Squeeze, Xen will silently convert the qcow images L1 table to big endian (you'll find "Converting image to big endian L1 table" in the logfiles), effectively rendering the image unusable on both Squeeze and Lenny!

== Note on kernel version compatibility ==

The new 2.6.32 kernel images have [[http://wiki.xensource.com/xenwiki/XenParavirtOps|paravirt_ops-based]] Xen dom0 and domU support.

When you create an image for a modern Debian or Ubuntu domU machine, it will include a kernel that has pv_ops domU support, it will therefore not use a Xen kernel, but the "stock" one, as it is capable of running on Xen's hypervisor.

== Possible problems and bugs ==

=== No login prompt when using `xm console` ===

Using a lenny domU, make sure you have {{{hvc0}}} listed in inittab, like {{{1:2345:respawn:/sbin/getty 38400 hvc0}}}. There happened to be a lot of changes of default console unit used by Xen (tty1, xvc0, hvc0 etc) but for a Lenny domU (version > 2.6.26-9) it's {{{hvc0}}}.

=== 'clocksource/0: Time went backwards' ===

If a domU crashes or freezes while uttering the famous lasts words 'clocksource/0: Time went backwards', your domU is likely using the xen clocksource instead of its own clock ticks. In practice, this seems to be the cause of infrequent lockups under load (and/or problems with suspending).

see http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1098

==== workaround #1 ====
A workaround is to decouple the clock in the domU from the dom0:

In your dom0 and domU {{{/etc/sysctl.conf}}} add the line: {{{xen.independent_wallclock=1}}}. On the dom0, edit the configuration file of the domU (e.g. {{{/etc/xen/foobar.cfg}}} and add (or expand) the extra-line: {{{extra="clocksource=jiffies"}}}.

These settings can be activated without rebooting the domU. After editing the configuration files, issue {{{sysctl -p}}} and {{{echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource}}} on the domU prompt.

Because the clock won't be relying on the dom0 clock anymore, you probably need to use ntp on the domU to synchronize it properly to the world.

==== workaround #2 ====
Another possibility ist to use the behaviour of the previous xen-kernel settings: clocksource=jiffies and independent_wallclock=0

Setting clocksource=jiffies for the dom0 and each domU as kernel parameter has eliminated the "Time went backwards" for me (14 dom0s and 27 domUs running stable for two weeks).
You can check the values with

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

and

cat /proc/sys/xen/independent_wallclock

With these settings, ntp ist only needed in the dom0. If you change the time in a domU while ntp is running on the according dom0, time will be corrected within a few minutes in the domU.
Hint: I didn't manage to influence the time of the domU with setting the time in the dom0 with date or hwclock, nevertheless ntp seems to do this (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534978#29).

==== workaround #3 ====

There are cases where setting the clocksource to jiffies just makes the clock more unstable and leads to continous resets. A working solution appears to be the following:

  * set independent_wallclock to 0 (all domains; VMs will follow dom0's clock)
  * set clocksource to xen (it's the default in lenny)
  * configure ntpd in dom0 only; set "disable kernel" in ntp.conf

This succeeded in stabilizing a Xen server's clock where all other workarounds failed.

More information can be found at http://my.opera.com/marcomarongiu/blog/2010/08/18/debugging-ntp-again-part-4-and-last. You can browse for the whole process at http://my.opera.com/marcomarongiu/blog/index.dml/tag/Sysadmin

=== domU on lenny using xen-tools ===
xen-tools don't use hvc0 as the console device in /etc/inittab and don't install udev (leading to /dev/pts missing in domU).

This makes logging in via xm console and via ssh impossible, because getty doesn't have a proper console to attach to and ssh can't attach to a pseudo terminal.

To fix this,

1. add to /etc/xen-tools/xen-tools.conf:

{{{
serial_device = hvc0}}}
2. and make domU with:

{{{
xen-create-image --hostname HOSTNAME (more options...) --role udev}}}


= Older Releases =

[[Xen_Installation_on_lenny|Xen Installation on Debian 5.0 ( Lenny )]]

[[Xen_Installation_on_etch |Xen Installation on Debian 4.0 ( Etch )]]

The page [[DebianInstaller/Xen]] contains instructions on how to install Xen Dom0 and Etch DomU with DebianInstaller.

= Package maintenance =
Debian's Xen packages are maintained by the [[http://alioth.debian.org/projects/pkg-xen/|pkg-xen]] project. ([[http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel|developers' mailing list]])

The [[http://qa.debian.org/developer.php?login=pkg-xen-devel@lists.alioth.debian.org|Debian Developer's Package Overview]] page lists source packages that are maintained by the team.

= Common Errors =
== dom0 automatic reboots ==
 . {i} Note: if Xen is crashing and reboot automatically, you may want to use {{{noreboot}}} xen option, to prevent it from rebooting automatically.

Edit /etc/default/grub and add the "noreboot" option to GRUB_CMDLINE_XEN, for example:

{{{
GRUB_CMDLINE_XEN="noreboot"
}}}

== Hangs on boot on system with >32G RAM ==
System with >32G RAM can hang on boot after "system has x VCPUS" and before "Scrubbing Free RAM". This is due to a limitation of the paravirt ops domain 0 kernel in Squeeze which prevents it from using more than 32G.

/!\ ToDo: bug report number?

Add "dom0_mem=32G" to your hypervisor command line to work around this issue.

The remaining RAM will still be available for guest use!

For example, edit /etc/default/grub and edit the variable:

{{{
GRUB_CMDLINE_XEN="dom0_mem=32G"
}}}

== Error "Device ... (vif) could not be connected" ==
You need to configure some basic networking between dom0 and domU.

The recommended way to do this is to configure bridgine in /etc/networkin/interfaces. See [[BridgeNetworkConnections]] and/or the Xen wiki page [[http://wiki.xen.org/wiki/Host Configuration/Networking|Host Configuration/Networking]] for details.

 . {i} Note: The use of the 'network-script' option in /etc/xen/xend-config.sxp is no longer recommended.

== "Error: Bootloader isn't executable" ==

/!\ ToDo: was this lenny-only?

The above, rather cryptic, error (when starting a domU using xen-utils/xm create) is due to xen-utils not being able to find PyGrub. Modify your xm-debian.cfg config file to use the absolute directory (ie. bootloader="/usr/lib/xen-3.2-1/bin/pygrub" instead of bootloader="pygrub") and your domU should boot up fine.

== "ERROR (XendCheckpoint:144) Save failed on domain mydomu32 (X)." ==

/!\ ToDo: was this lenny-only?

xm save/migration of a 32-Bit domU on a 64-Bit dom0 fails. It seems this is not supported with linux-image-2.6.26-2-xen-amd64 (http://readlist.com/lists/lists.xensource.com/xen-users/4/24225.html). One workaround is to use a 64-Bit Hypervisor with a 32-Bit dom0 (http://lists.xensource.com/archives/html/xen-users/2008-12/msg00404.html).
See also DebianBug:526695

== "network routing for hvm guests:" ==
=== ERROR in /var/log/xen/qemu-dm-[.*].log: ===
=== bridge xenbr0 does not exist! ===
=== /etc/xen/scripts/qemu-ifup: could not launch network script ===

When using routing instead of bridging there seems to be problems for hvm guests. Here a very bad hack for it:
prerequsites:

in "/etc/xen/xend-config.sxp"

 . {{{
(network-script 'network-route netdev=<ethX,internet_you_want_to_use>')
(vif-script vif-route)
 }}}

in your domU config file

 . {{{
...
vif = [ 'type=ioemu, mac=00:16:3e:XX:XX:XX, vifname=vif-<domU-name>, ip=<domU-ip>, bridge=<ethX,nic_you_want_to_use>' ]
...
 }}}

than:

In "/etc/xen/scripts/qemu-ifup" disable with a #

 . {{{
# brctl addif $2 $1
 }}}

insert

 . {{{
gwip=`ip -4 -o addr show primary dev "$2" | awk '$3 == "inet" {print $4;exit}'| sed 's#/.*##'`
ip link set "$1" up arp on
ip addr add $gwip dev "$1"
   }}}

after starting you domU

 . {{{
ip route show

ip route del <domU-ip> dev vif-<domU-name>

ip addr show (should show a tap device with your <dom0-IP of the ethX,nic_you_want_to_use>)

ip route add to <domU-ip> via <dom0-IP of the ethX,nic_you_want_to_use> dev tapX
 }}}

pretty bad but works...



== "network bridging for xen 4.0 with multiple interfaces:" ==
see Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456

Using xen 4.0 under squeeze I had trouble to let my domUs use a specific nic in dom0.
The bugfix above might not be fully sufficient to solve it, here is what you have to do:

1.) in set /etc/xen/xend-config.sxp "(network-script network-bridge-wrapper)"

2.) create /etc/xen/scriptsnetwork-bridge-wrapper like this (don't forget to chmod 755):

. {{{

#(!)/bin/bash
# next two lines were good for xen-3.2.1 not for xen-4.0x anymore
#/etc/xen/scripts/network-bridge netdev=eth0 bridge=xenbr0 start
#/etc/xen/scripts/network-bridge netdev=eth1 bridge=xenbr1 start

# this works for xen-4.0x
# xen-utils-common in squeeze don't produce this script (yet) which is needed

if [ ! -f ../scripts/hotplugpath.sh ];then
        echo -e "SBINDIR=\"/usr/sbin\"
BINDIR=\"/usr/bin\"
LIBEXEC=\"/usr/lib/xen/bin\"
LIBDIR=\"/usr/lib\"
SHAREDIR=\"/usr/share\"
PRIVATE_BINDIR=\"/usr/lib/xen/bin\"
XENFIRMWAREDIR=\"/usr/lib/xen/boot\"
XEN_CONFIG_DIR=\"/etc/xen\"
XEN_SCRIPT_DIR=\"/etc/xen/scripts\"" > /etc/xen/scripts/hotplugpath.sh
        chown root:root /etc/xen/scripts/hotplugpath.sh
        chmod 755 /etc/xen/scripts/hotplugpath.sh
fi

/etc/xen/scripts/network-bridge netdev=eth0 start

# if you want to bind a NIC in domU to another interface in dom0 (bridging mode) than:
# 1.) list all dom0 interfaces you want to be able to use (except your eth0!) in "more_bridges" below
# 2.) in the domU config use: vif = [ 'mac=00:16:3e:xx:xx:xx, bridge=ethX' ] with ethX being the original device of dom0 that this domU should use
# 3.) using bridging, all interfaces in dom0 that you want to use have to be valid configured BEFORE you run this script, i.e. before starting xend the first time.
# (use ping -I ethX <target your gateway> to CHECK THAT BEFORE, and don't blame me if u plugged the cable into the wrong nic port ;-)
# 4.) remember, in the background xen does move the link to another name, creates a new interface etc etc... we don't care about this here, it just works fine for now

# here I want to prepare to other nics that I can choose from in the domU configs
more_bridges="eth1 eth2"

for i in $more_bridges; do
        ip addr show dev $i | egrep inet > /dev/null 2>&1
        if [ $? == 0 ];then
                ip link set $i down
                /etc/xen/scripts/network-bridge netdev=$i start
                ip link set $i up
        else
                echo -e "\nFailed to set up a bridge!\nYour device $i in dom0 seems not to be configured, so I won't try to use it as part of a bridge for any domU\n"
        fi
done

 }}}

I tested this, it worked and had no side effects on the first glance, still there is no guarantee ;-)


== "XENBUS: Device with no driver: device/vbd/..." ==

/!\ ToDo: was this lenny-only?

This means you do not have xen-blkfront/xen-blkback driver loaded.

If you're upgrading from 2.6.26.x (or any other old version) to 2.6.32.x domU kernel,
update-initramfs (running in 2.6.26.x environment) fails to recognize the need for
xen-*front modules and will not include these in initrd image, causing reboot to fail.

OTOH, if you do have xen-*.ko modules in initrd image, this message can be ignored.
Drivers will be loaded in later stage automatically.

= PV drivers on HVM guest =

It may be possible to build the PV drivers for use on HVM guests. These drivers are called unmodified_drivers and are part of the xen-unstable.hg repository. You can fetch the repository using mercurial thus:

 . {{{
  hg clone http://xenbits.xen.org/xen-unstable.hg
}}}
The drivers reside under xen-unstable.hg/unmodified_drivers/linux-2.6. The README in this directory gives compilation instructions.

A somewhat dated, detailed set of instructions for building these drivers can be found here:

http://wp.colliertech.org/cj/?p=653
  

= Resources =
 * Two-way migration between Xen and KVM is described here: [[HowToMigrateBackAndForthBetweenXenAndKvm]]
 * Homepage :http://www.xen.org
 * (quite basic and low-level) Upstream Documentation is on package {{{xen-docs-3.0}}} package (in /usr/share/doc/xen-docs-3.0/user.pdf.gz). It's also available [[http://xen.org/xen/documentation.html|online]].
 * Xen Wiki :
  * [[http://wiki.xen.org/wiki/Category:Debian|Debian]]
  * [[http://wiki.xen.org/wiki/Category:FAQ|XenFaq]]
  * [[http://wiki.xen.org/wiki/XenNetworking|Xen Networking]]
  * [[http://wiki.xen.org/wiki/XenNetworking/Examples|Xen Networking Examples]]
  * [[http://wiki.xen.org/wiki/XenBestPractices|Best Practices for Xen]]
 * German Wiki on Xen: http://www.xen-info.de/wiki
 * Additional information required:
  * Compiling a custom Xen DomU kernel. (e.g. adding tun device)
 * [[http://www2.fh-lausitz.de/launic/comp/xen/101212.xen4_update_vm|Script, notes to migrate para-vm to xen-4.0]]
----
CategoryNetwork

Translation(s): ?Indonesian

(!) ?/Discussion


Xen Overview

Modern computers are sufficiently powerful to use virtualization to present the illusion of many smaller virtual machines (VMs), each running a separate operating system instance. Successful partitioning of a machine to support the concurrent execution of multiple operating systems poses several challenges. Firstly, virtual machines must be isolated from one another: it is not acceptable for the execution of one to adversely affect the performance of another. This is particularly true when virtual machines are owned by mutually untrusting users. Secondly, it is necessary to support a variety of different operating systems to accommodate the heterogeneity of popular applications. Thirdly, the performance overhead introduced by virtualization should be small.

Xen is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Xen is Open Source software, released under the terms of the GNU General Public License. We have a fully functional ports of Linux 2.6 running over Xen, and regularly use it for running demanding applications like MySQL, Apache and PostgreSQL. Any Linux distribution (RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS.

In addition to Linux, members of Xen's user community have contributed or are working on ports to other operating systems such as NetBSD (Christian Limpach), FreeBSD (Kip Macy) and Plan 9 (Ron Minnich).

Different types of virtualization offered by Xen

There are two different types of virtualization offered by Xen:

  • Para-virtulization and
  • Hardware-supported virtualization

Para-virtualization

A term used to describe a virtualization technique that allows the operating system to be aware that it is running on a hypervisor instead of base hardware. The operating system must be modified to accommodate the unique situation of running on a hypervisor instead of basic hardware.

Hardware Virtual Machine

A term used to describe an operating system that is running in a virtualized environment unchanged and unaware that it is not running directly on the hardware. Special hardware is required to allow this, thus the term HVM.

(Source: What is Xen Hypervisor, www.xen.org)

Domain 0 (Host) Installation

The Xen and debootstrap software in Squeeze (Debian 6.0) are very much newer than that in Lenny. Because of that, working with Xen becomes a lot easier.

The setup described here is tested for Debian Lenny and Ubuntu Maverick virtual machines, but should work for a lot more.

First install the hypervisor, xen kernel and xen-tools. This can be done by a metapackage:

aptitude -P install xen-linux-system

To get Xen HVM support Xen 4.0 Wiki

apt-get install xen-qemu-dm-4.0

Debian Squeeze uses Grub 2 whose default is to list normal kernels first, and only then list the Xen hypervisor and its kernels.

You can change the default kernel to boot in two ways:

  • Change the priority of GRUB's Xen configuration script (20_linux_xen) to be higher than the standard Linux config (10_linux):

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

to undo this:

dpkg-divert --rename --remove /etc/grub.d/20_linux_xen
  • Modify the value of GRUB_DEFAULT in the file /etc/default/grub. The value is an integer starting at 0 representing the order of the menuentry item to boot. You can see a list of all menuentry values in order by typing

grep menuentry /boot/grub/grub.cfg

Count to the number of the first Xen kernel, starting at 0, and enter it in the default file. Note that this procedure is not robust against the installation or removal of new kernel versions which will cause the Xen entries to get different numbers, for this reason reordering the priorities using dpkg-divert as above is preferable.

After either of these procedures, do an update to the GRUB configuration:

update-grub

If you wish to improve this process there is an open bug discussing the default values after a Xen installation. #603832

To avoid getting boot entries for each virtual machine you install on a volume group, disable the GRUB OS prober.

/!\ ToDo: does this problem still happen and under what circumstances? Bug number?

Note that if you are running a computer with multi-boot with for example Windows, this will also remove the entries for it, which might not be what you wish for.

Edit /etc/default/grub and add:

# Disable OS prober to prevent virtual machines on logical volumes from appearing in the boot menu.
GRUB_DISABLE_OS_PROBER=true

You may also want to pass some boot parameters to Xen when starting up in normal or recovery mode. Add these variables to /etc/default/grub to achieve this:

# Xen boot parameters for all Xen boots
GRUB_CMDLINE_XEN="something"
# Xen boot parameters for non-recovery Xen boots (in addition to GRUB_CMDLINE_XEN)
GRUB_CMDLINE_XEN_DEFAULT="something else"

After editing GRUB configuration, you must apply it by running:

update-grub

By default, when Xen dom0 shuts down or reboots, it tries to save the state of the domUs. Sometimes there are problems with that - it could fail because of a lack of disk space in /var, or because of random software bugs. Because it is also clean to just have the VMs shutdown upon host shutdown, if you want you can make sure they get shut down normally by setting these parameters in /etc/default/xendomains:

XENDOMAINS_RESTORE=false
XENDOMAINS_SAVE=""

It is recommended that you manage your own network bridge using the Debian network bridge. The Xen supplied network scripts are not always reliable and will be removed from a later version.

Should you still wish to use them, in /etc/xen/xend-config.sxp enable the network bridge by commenting out the line that was already there for that. (You may check XenNetworking page in Xen wiki.)

(network-script 'network-bridge antispoof=yes')

The antispoof=yes will activate Xen firewall to prevent that one of your VM uses an IP that it is not allowed to use (for example, if a domU was to use the gateway as its IP, it could seriously break your network, this will prevent it). In this case, you will need to specify the IP of your domU in the vif statement of your domUs.

If you get "missing vif-script, or network-script, in the Xen configuration file", try adding executable permission in:

chmod +x /etc/xen/scripts/*

This config file also has options to set the memory and CPU usage for your dom0, which you might want to change. To reduce dom0 memory usage as it boots, use the dom0_mem kernel option in the aforementioned GRUB_CMDLINE_XEN variable. Xen wiki also advise to disable dom0 memory ballooning and set minimal memory in /etc/xen/xend-config.sxp (1024M is an example) :

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

Serial console access

To get output from GRUB, the Xen hypervisor, the kernel and getty (login prompt) via both VGA and serial console to work, here's an example of the right settings on squeeze:

Edit /etc/default/grub and add:

GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1"
GRUB_TERMINAL="console serial"
GRUB_TIMEOUT=5
GRUB_CMDLINE_XEN="com1=9600,8n1 console=com1,vga"
GRUB_CMDLINE_LINUX="console=tty0 console=hvc0"

Here's what I used to configure the serial console (for a Supermicro X8STi-F motherboard with IPMI and SOL):

GRUB_CMDLINE_XEN="loglvl=all guest_loglvl=all com1=115200,8n1,0x3e8,5 console=com1,vga"
GRUB_CMDLINE_LINUX="console=hvc0 earlyprintk=xen"

In /etc/inittab you need at least these lines:

1:2345:respawn:/sbin/getty 38400 hvc0
2:23:respawn:/sbin/getty 38400 tty1
# NO getty on ttyS0!

This way, tty1 will show up at the VGA output, and the hvc0 will show up at the serial console.

To keep both Xen and dom0 kernel output on the same tty, just omit the "vga"-related settings from the above setup.

If you need to debug Xen and see a crash dump of the kernel, you can do it using IPMITool if your server has SOL:

ipmitool -I lanplus -H server-ip-address -U your-username sol activate | tee my-log-file.txt

Installation as a DomU (guest)

Using xen-tools

xen-tools is a set of scripts which can easily create fully configured Xen guest domains.

Once you have installed dom0 you can install on your host with:

apt-get install xen-tools

Then you can create virtual machines with this command:

xen-create-image --hostname <hostname> --ip <ip> --vcpus 2 --pygrub --dist <lenny|maverick|whatever>

To configure xen-tools, you can edit /etc/xen-tools/xen-tools.conf which contains default values that the xen-create-image script will use.

Read the xen-create-image manual page for information on the available options.

In case you use xen-tools with --role be aware of #588783.

These are some real-life examples of params that may need to be changed:

# Virtual machine disks are created as logical volumes in volume group 'universe' (hint: LVM storage is much faster than file)
lvm = universe
 
size   = 50Gb      # Disk image size.
memory = 512Mb    # Memory size
swap   = 2Gb    # Swap size
 
# Default gateway and netmask for new VMs
gateway    = x.x.x.x
netmask    = 255.255.255.0
 
# When creating an image, interactively setup root password
passwd = 1
 
# Let xen-create-image use pygrub, so that the grub from the VM is used, which means you no longer need to store kernels outside the VMs. Keeps things very flexible.
pygrub=1

Possible problems and bugs

  • If your domU kernel happens to miss support for the xvda* disk devices (the xen-blkfront driver), use the --scsi option that makes the VM use normal SCSI HD names like sda*. You can also set scsi=1 in /etc/xen-tools/xen-tools.conf to make this the default.
  • Debian Bug #584152 Error during xen-create-image: mkfs.ext3: /lib/libblkid.so.1: version `BLKID_2.17' not found (required by mkfs.ext2). Solve this by downgrading the mkfs tool.

  • Error starting xend 3.4. Use the 4.x from current squeeze packages. Xen Bug #1620

  • PvGrub exists, but PvGrub is not packaged in squeeze, cf. 588839, PvGrub on Xen Wiki

  • On an Intel Corporation Core Processor Integrated Graphics Controller (rev 02) using the i915 module, X fails. This means if you have GDM or any other display manager installed you will not be able to use your computer after booting into a Xen hypervisor. Disabling GDM is a work around but X.org continues to lock up the keyboard and screen if started manually via startx.

Using Debian Installer

The Xen wiki page Debian Guest Instalation Using DebianInstaller contains instructions on how to install Xen DomU from Lenny onwards using ?Debian Installer.

Upgrading/transition

See also: Debian Release Notes

Upgrading a server to Squeeze that uses both Lenny Dom0 and DomU's is fairly straightforward. There are a few catches that one needs to be aware of however: Reference

  • Dom0 Issues

    • The Xen packages will not upgrade themselves. They must be manually removed and the latest Xen packages must be installed from the Debian Squeeze repository through apt.
    • pygrub in Xen-4.0 will need to be patched as per #599243

    • xen.independent_wallclock sysctl setting is not available for newer squeeze kernels supporting pvops. If you have relied on it, you would have to run ntpd in dom0 and domUs. source

  • DomU Issues

    • A Squeeze DomU will not be able to boot on the Xen-3.2 package supplied by Lenny because this older version will not support grub2. A Lenny DomU can be upgraded to Squeeze while running on a Lenny Dom0 but it will not be able to be booted until the Dom0 has been upgraded to the Xen-4.0 packages.
    • The entries added to chain load grub1 to grub2 will not allow pygrub to find the correct partition. Before rebooting a freshly upgraded Squeeze DomU, make sure to rename or remove /boot/grub/menu.lst. This will force pygrub to look for the /boot/grub/grub.cfg file which will be in the correct format.
    • A qcow image created with qcow-create and the BACKING_FILENAME option on Lenny will not be able to boot on Squeeze because the ability to use qcow images as backing files has been removed in Xen versions after 3.2. Also, if you try to boot such an image on Squeeze, Xen will silently convert the qcow images L1 table to big endian (you'll find "Converting image to big endian L1 table" in the logfiles), effectively rendering the image unusable on both Squeeze and Lenny!

Note on kernel version compatibility

The new 2.6.32 kernel images have paravirt_ops-based Xen dom0 and domU support.

When you create an image for a modern Debian or Ubuntu domU machine, it will include a kernel that has pv_ops domU support, it will therefore not use a Xen kernel, but the "stock" one, as it is capable of running on Xen's hypervisor.

Possible problems and bugs

No login prompt when using `xm console`

Using a lenny domU, make sure you have hvc0 listed in inittab, like 1:2345:respawn:/sbin/getty 38400 hvc0. There happened to be a lot of changes of default console unit used by Xen (tty1, xvc0, hvc0 etc) but for a Lenny domU (version > 2.6.26-9) it's hvc0.

'clocksource/0: Time went backwards'

If a domU crashes or freezes while uttering the famous lasts words 'clocksource/0: Time went backwards', your domU is likely using the xen clocksource instead of its own clock ticks. In practice, this seems to be the cause of infrequent lockups under load (and/or problems with suspending).

see http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1098

workaround #1

A workaround is to decouple the clock in the domU from the dom0:

In your dom0 and domU /etc/sysctl.conf add the line: xen.independent_wallclock=1. On the dom0, edit the configuration file of the domU (e.g. /etc/xen/foobar.cfg and add (or expand) the extra-line: extra="clocksource=jiffies".

These settings can be activated without rebooting the domU. After editing the configuration files, issue sysctl -p and echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource on the domU prompt.

Because the clock won't be relying on the dom0 clock anymore, you probably need to use ntp on the domU to synchronize it properly to the world.

workaround #2

Another possibility ist to use the behaviour of the previous xen-kernel settings: clocksource=jiffies and independent_wallclock=0

Setting clocksource=jiffies for the dom0 and each domU as kernel parameter has eliminated the "Time went backwards" for me (14 dom0s and 27 domUs running stable for two weeks). You can check the values with

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

and

cat /proc/sys/xen/independent_wallclock

With these settings, ntp ist only needed in the dom0. If you change the time in a domU while ntp is running on the according dom0, time will be corrected within a few minutes in the domU. Hint: I didn't manage to influence the time of the domU with setting the time in the dom0 with date or hwclock, nevertheless ntp seems to do this (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534978#29).

workaround #3

There are cases where setting the clocksource to jiffies just makes the clock more unstable and leads to continous resets. A working solution appears to be the following:

  • set independent_wallclock to 0 (all domains; VMs will follow dom0's clock)
  • set clocksource to xen (it's the default in lenny)
  • configure ntpd in dom0 only; set "disable kernel" in ntp.conf

This succeeded in stabilizing a Xen server's clock where all other workarounds failed.

More information can be found at http://my.opera.com/marcomarongiu/blog/2010/08/18/debugging-ntp-again-part-4-and-last. You can browse for the whole process at http://my.opera.com/marcomarongiu/blog/index.dml/tag/Sysadmin

domU on lenny using xen-tools

xen-tools don't use hvc0 as the console device in /etc/inittab and don't install udev (leading to /dev/pts missing in domU).

This makes logging in via xm console and via ssh impossible, because getty doesn't have a proper console to attach to and ssh can't attach to a pseudo terminal.

To fix this,

1. add to /etc/xen-tools/xen-tools.conf:

serial_device = hvc0

2. and make domU with:

xen-create-image --hostname HOSTNAME (more options...) --role udev

Older Releases

Xen Installation on Debian 5.0 ( Lenny )

Xen Installation on Debian 4.0 ( Etch )

The page ?DebianInstaller/Xen contains instructions on how to install Xen Dom0 and Etch DomU with DebianInstaller.

Package maintenance

Debian's Xen packages are maintained by the pkg-xen project. (developers' mailing list)

The Debian Developer's Package Overview page lists source packages that are maintained by the team.

Common Errors

dom0 automatic reboots

  • {i} Note: if Xen is crashing and reboot automatically, you may want to use noreboot xen option, to prevent it from rebooting automatically.

Edit /etc/default/grub and add the "noreboot" option to GRUB_CMDLINE_XEN, for example:

GRUB_CMDLINE_XEN="noreboot"

Hangs on boot on system with >32G RAM

System with >32G RAM can hang on boot after "system has x VCPUS" and before "Scrubbing Free RAM". This is due to a limitation of the paravirt ops domain 0 kernel in Squeeze which prevents it from using more than 32G.

/!\ ToDo: bug report number?

Add "dom0_mem=32G" to your hypervisor command line to work around this issue.

The remaining RAM will still be available for guest use!

For example, edit /etc/default/grub and edit the variable:

GRUB_CMDLINE_XEN="dom0_mem=32G"

Error "Device ... (vif) could not be connected"

You need to configure some basic networking between dom0 and domU.

The recommended way to do this is to configure bridgine in /etc/networkin/interfaces. See BridgeNetworkConnections and/or the Xen wiki page Host Configuration/Networking for details.

  • {i} Note: The use of the 'network-script' option in /etc/xen/xend-config.sxp is no longer recommended.

"Error: Bootloader isn't executable"

/!\ ToDo: was this lenny-only?

The above, rather cryptic, error (when starting a domU using xen-utils/xm create) is due to xen-utils not being able to find PyGrub. Modify your xm-debian.cfg config file to use the absolute directory (ie. bootloader="/usr/lib/xen-3.2-1/bin/pygrub" instead of bootloader="pygrub") and your domU should boot up fine.

"ERROR (XendCheckpoint:144) Save failed on domain mydomu32 (X)."

/!\ ToDo: was this lenny-only?

xm save/migration of a 32-Bit domU on a 64-Bit dom0 fails. It seems this is not supported with linux-image-2.6.26-2-xen-amd64 (http://readlist.com/lists/lists.xensource.com/xen-users/4/24225.html). One workaround is to use a 64-Bit Hypervisor with a 32-Bit dom0 (http://lists.xensource.com/archives/html/xen-users/2008-12/msg00404.html). See also 526695

"network routing for hvm guests:"

ERROR in /var/log/xen/qemu-dm-[.*].log:

bridge xenbr0 does not exist!

/etc/xen/scripts/qemu-ifup: could not launch network script

When using routing instead of bridging there seems to be problems for hvm guests. Here a very bad hack for it: prerequsites:

in "/etc/xen/xend-config.sxp"

  • (network-script 'network-route netdev=<ethX,internet_you_want_to_use>')
    (vif-script vif-route)

in your domU config file

  • ...
    vif = [ 'type=ioemu, mac=00:16:3e:XX:XX:XX, vifname=vif-<domU-name>, ip=<domU-ip>, bridge=<ethX,nic_you_want_to_use>' ]
    ...

than:

In "/etc/xen/scripts/qemu-ifup" disable with a #

  • # brctl addif $2 $1 

insert

  • gwip=`ip -4 -o addr show primary dev "$2" | awk '$3 == "inet" {print $4;exit}'| sed 's#/.*##'`
    ip link set "$1" up arp on
    ip addr add $gwip dev "$1"

after starting you domU

  • ip route show
    
    ip route del <domU-ip> dev vif-<domU-name>
    
    ip addr show (should show a tap device with your <dom0-IP of the ethX,nic_you_want_to_use>)
    
    ip route add to <domU-ip> via <dom0-IP of the ethX,nic_you_want_to_use> dev tapX

pretty bad but works...

"network bridging for xen 4.0 with multiple interfaces:"

see Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456

Using xen 4.0 under squeeze I had trouble to let my domUs use a specific nic in dom0. The bugfix above might not be fully sufficient to solve it, here is what you have to do:

1.) in set /etc/xen/xend-config.sxp "(network-script network-bridge-wrapper)"

2.) create /etc/xen/scriptsnetwork-bridge-wrapper like this (don't forget to chmod 755):

.

#(!)/bin/bash
# next two lines were good for xen-3.2.1 not for xen-4.0x anymore
#/etc/xen/scripts/network-bridge netdev=eth0 bridge=xenbr0 start
#/etc/xen/scripts/network-bridge netdev=eth1 bridge=xenbr1 start

# this works for xen-4.0x
# xen-utils-common in squeeze don't produce this script (yet) which is needed

if [ ! -f ../scripts/hotplugpath.sh ];then
        echo -e "SBINDIR=\"/usr/sbin\"
BINDIR=\"/usr/bin\"
LIBEXEC=\"/usr/lib/xen/bin\"
LIBDIR=\"/usr/lib\"
SHAREDIR=\"/usr/share\"
PRIVATE_BINDIR=\"/usr/lib/xen/bin\"
XENFIRMWAREDIR=\"/usr/lib/xen/boot\"
XEN_CONFIG_DIR=\"/etc/xen\"
XEN_SCRIPT_DIR=\"/etc/xen/scripts\"" > /etc/xen/scripts/hotplugpath.sh
        chown root:root /etc/xen/scripts/hotplugpath.sh
        chmod 755 /etc/xen/scripts/hotplugpath.sh
fi

/etc/xen/scripts/network-bridge netdev=eth0 start

# if you want to bind a NIC in domU to another interface in dom0 (bridging mode) than:
# 1.) list all dom0 interfaces you want to be able to use (except your eth0!) in "more_bridges" below
# 2.) in the domU config use: vif = [ 'mac=00:16:3e:xx:xx:xx, bridge=ethX' ] with ethX being the original device of dom0 that this domU should use
# 3.) using bridging, all interfaces in dom0 that you want to use  have to be valid configured BEFORE you run this script, i.e. before starting xend the first time.
#       (use ping -I ethX <target your gateway> to CHECK THAT BEFORE, and don't blame me if u plugged the cable into the wrong nic port ;-)
# 4.) remember, in the background xen does move the link to another name, creates a new interface etc etc... we don't care about this here, it just works fine for now

# here I want to prepare to other nics that I can choose from in the domU configs
more_bridges="eth1 eth2"

for i in $more_bridges; do
        ip addr show dev $i | egrep inet > /dev/null 2>&1
        if [ $? == 0 ];then
                ip link set $i down
                /etc/xen/scripts/network-bridge netdev=$i start
                ip link set $i up
        else
                echo -e "\nFailed to set up a bridge!\nYour device $i in dom0 seems not to be configured, so I won't try to use it as part of a bridge for any domU\n"
        fi
done

I tested this, it worked and had no side effects on the first glance, still there is no guarantee ;-)

"XENBUS: Device with no driver: device/vbd/..."

/!\ ToDo: was this lenny-only?

This means you do not have xen-blkfront/xen-blkback driver loaded.

If you're upgrading from 2.6.26.x (or any other old version) to 2.6.32.x domU kernel, update-initramfs (running in 2.6.26.x environment) fails to recognize the need for xen-*front modules and will not include these in initrd image, causing reboot to fail.

OTOH, if you do have xen-*.ko modules in initrd image, this message can be ignored. Drivers will be loaded in later stage automatically.

PV drivers on HVM guest

It may be possible to build the PV drivers for use on HVM guests. These drivers are called unmodified_drivers and are part of the xen-unstable.hg repository. You can fetch the repository using mercurial thus:

  •   hg clone http://xenbits.xen.org/xen-unstable.hg

The drivers reside under xen-unstable.hg/unmodified_drivers/linux-2.6. The README in this directory gives compilation instructions.

A somewhat dated, detailed set of instructions for building these drivers can be found here:

http://wp.colliertech.org/cj/?p=653

Resources


CategoryNetwork