Interesting stuff about Computers, Linux and Life
Xen is nowadays a widespread approach to run virtual hosts. Thanks to its flexible configuration it’s not only possible to run virtual Linux hosts but nearly any operating system that is compatible to the Xen hypervisor machine architecture will possibly run as guest host. The Xen paravirtualization Read the rest of this entry »
Recently I wanted to set up a testing server for the different virtualization techniques for Linux. For this I have an Asus P5LD2 mainboard with an Intel dual core Pentium D 3,2 GHz which supports the Virtual Machine Extensions (VMX). Thanks to this I can compile Xen with the ‘hvm’ USE-flag and run fully virtualized guest operating systems on my Xen supervisor. This means I could run nearly every i386 compatible operating system (even Windows 
) in my Xen environment. Without such hardware every guest operating system has to have a Xen enabled kernel.
Another approach with the same result is the open source project QEMU. Its abstraction level is higher than with Xen and it can even emulate different target architectures from your current x86 host. So far x86_64, ARM, SPARC, PowerPC, MIPS and M68k target systems are supported. Its guest operating system does not need any single change to run on QEMU. This makes it very comfortable to test new live CDs or operating system images. But it is not so trivial to setup QEMU and Xen together on a Gentoo machine.
How to setup QEMU on 32bit Gentoo in Xen dom0?
If you compile Xen on a 32bit host you have to add ‘-mno-tls-direct-seg-refs’ to your CFLAGS. That is because the glibc TLS library is implemented in a way that will conflict with how Xen uses segment registers. For compiling the non-patched QEMU 0.9.0 you have to use a gcc version 3.x. The nowadays default gcc 4.x is not yet supported. After several compile failures I finally found to setup QEMU the following way:
1. For compiling gcc-3.x remove the ‘-mno-tls-direct-seg-refs’ from /etc/make.conf and set the ‘nossp’ and ‘nopie’ USE-flags. Otherwise gcc or later qemu will not compile.
2. Switch to gcc-3.x before compiling qemu-softmmu, qemu-user and qemu. In my case it’s: gcc-config i686-pc-linux-gnu-3.3.6
3. Check your CFLAGS again because the optimization flags for gcc 4.x are not always backwards compatible to gcc-3.x. In my case the make.conf looks like this:
# gcc-3.x
CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs"
# gcc-4.x for compiling gcc-3.3
#CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
# gcc-4.x
#CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs"
4. Now you can compile QEMU. Do not forget to switch back to your original CFLAGS and gcc-4.x after successfully emerging QEMU. I recommend to you to also build the QEMU kernel accelerator module kqemu which has to be compiled with the same compiler as the kernel itself.
Now Xen and QEMU are able to run whatever operating system image you give them. Have fun with playing around…
Continuative links:
YES, YES, YES! Finally I made it.
Since a while I am playing with the migration functionality of a Xen domU between two Xen servers. It allows to move a virtual machine without reboot between two physical machines. But my problem was: It did not hold what it promised.
Trying all possible versions of Xen and the xen-sources in the Gentoo Portage I was able to migrate a domU but not when it was configured as SMP machine. After I found that the kernel has to include the CONFIG_HOTPLUG_CPU option, I was able to migrate the domU at least one time from one host to the other. When repeating this procedure the domU crashed with a kernel oops. By finally trying the latest Xen 3.1 version from the unofficial mescalito portage overlay with the xen-sources-2.6.18, repeated migration of a domU between the Xen servers does work now. Prerequisite is that both dom0 and domU run the 2.6.18 kernel. I am trying to run this in production now and will see how reliable it is.
I just remember that I did also remove the memory restriction from the dom0. The dom0_mem parameter in the grub configuration is optional and when omitting it the dom0 can use the unused memory for itself.
For my home server I wanted to act a Xen domU as CUPS printing server. Therefore I needed access to my parallel printer connected to the Xen server. How are I/O-ports handled in Xen?
The I/O-addresses of the devices which can be found with cat /proc/ioports can be redirected from the Xen dom0. You have to enter the address range of the device you want to use in a domU in their configuration file (/etc/xen/domain-config). For my parallel port it would be:
ioports = [ '0278-027a' ]
Further I make sure that my dom0 does not access the device by removing parallel port support in the kernel configuration. When you boot then a domU kernel with parallel port and printer support it can access the device natively. Here a cut out from dmesg:
parport0: PC-style at 0x278 [PCSPP,TRISTATE]
parport0: Printer, Hewlett-Packard HP LaserJet 6P
lp0: using parport0 (polling).
In CUPS the printer is now accessible under /dev/lp0.
Unfortunately the documentation about this feature of Xen is a little bit rare. Another interesting thing is the redirection of PCI devices to a domU. Unfortunately I did not test this at my setup yet. I hope to come back to this topic later. For your creativity here some more examples from the net: