After a short power blackout last week (which luckily do not happen often here), my server at home did not want to start up anymore. After some detailed investigations I found a hardware error on one of the local hard drives. Taking both the necessicty of changing the disk and the age of the OS installation (it still had been a the current vmware-any-any-patches properly on the current FC12’s kernel. I was about to give up, but then I remembered that there were two other virtual machine solutions available: QEMU and XEN.

XEN

First having tried to port to XEN, I soon had to realise that this is not possible. As of recent Fedora Cores, there is currently no support for the so-called dom0 part of XEN which means that the current host kernels do not have the necessary adjustments in place for allowing XEN clients (irrespectively of the guests OS) to run. You would need special kernel versions which are flagged as testing. Although I am no coward and I would not consider this system to be “in a productive environment”, I still did not want to install that one. So I decided to give QEMU a try.

QEMU

There, I immediately crashed into a very popular problem apparently: My guest OS, which I was not able to boot any more (because my very oldish VMware installation was already gone), had been installed with a SCSI drive (lsilogic) as the master disk where the guest OS had been installed. QEMU, however, normally only supports integration of IDE disks for booting the operating system. Fortunately, I learned how to deal with this from a blog post at geekyfacts.com which is for xen machines. Nevertheless, the first two sections are still valid for a conversion from VMWare to QEMU. Seeing the trick with Microsoft’s KB article and the neccesity of adjusting the registry, I was forced to install a VMware version (on some other host) temporarily. During the installation I read the blog post of Ian about to exchange the HAL possibility. Out of this I feared that I would also have to do this, because my previous installation (of the host OS) was not ACPI-enabled. His article, unfortunately, is somewhat vague under which conditions an exchange of the HAL is necessary or not. After having made the adjustments, I was lucky to see that I did not have to exchange the HAL in my case.

Trouble with Network in Bridging Mode

However, still the system did not boot up yet. The system was able to find its boot device again, but during startup the system was hanging at “Computer is starting”. It took me several hours to determine that this is related to the fact that not just the boot device had changed but also the virtual network adapter. As the ActiveDirectory of a Windows Server OS is using the MAC address for certain operations (to have a unique value) the exchange of the network adapter which also was not connected to a physical LAN (yet) caused that the network adapter was not receiving any IP address via DHCP (that is the default on any new network adapter). Booting in the guest OS in Safe Mode I was able to set an IP address manually. This made the system boot up again, but still I wanted a plain bridge mode. A NAT approach does not make sense to me, because the (virtual) server shall be available to the entire local network without restriction. At that time I was using Redhat’s virt-manager. As of today the latest version available with the FC12 distribution is revision 0.8.2. There I was not able to figure out how to set the virtual machine’s network adapter into bridge mode: When configurating a network adapter I always only got the option of “Virtual network ‘default’: NAT” which is exactly the way that I don’t want to have it (I read a blog article about version 0.8.3 which should enhance the UI there). I therefore returned back to the command line and checked for the TUN/TAP approach. There is a magnificant blog post by Alan Tan on the topic of QEMU TAP bridge configuration which I liked very much. However, there is one point in there which I considered too complex: the TAP device is being created during boot up. With recent QEMU versions there is the opportunity to specify a qemu-tap-up and a qemu-tap-down script for example like this:

qemu -net nic -net tap,name=tap0,script=/srv/qemu-tap-up,downscript=/srv/qemu-tap-down

These scripts are being called on startup and on shutdown of the virtual machine to do necessary adjustments for the TAP devices. My idea here simply is to let my local network card always run in bridge mode (i.e. I configure a bridge br0 with one single physical device eth0 assigning the IP address to the br0 device) and assigning and deassign the newly created tap device to that bridge via the scripts above. The fact that qemu passes the name of the currently used TAP device to the up- and down script as first argument comes in handy as well. Therefore my qemu-tap-up script reads as follows:

#!/bin/bash

ifconfig $1 up
brctl addif br0 $1

whereas qemu-tap-down is as simple as that:

#!/bin/bash

brctl delif br0 $1
ifconfig $1 down

And here is the abbreviated version of my /etc/sysconfig/network-scripts/ifcfg-eth0 file:

DEVICE=eth0
HWADDR=00:xx:yy:zz:aa:bb
ONBOOT=yes
BOOTPROTO=none
TYPE=Ethernet
IPV6INIT=no
USERCTL=no
NM_CONTROLLED=no
PREFIX=25
NAME="System eth0"
BRIDGE=br0

I added a new /etc/sysconfig/network-scripts/ifcfg-br0 file which now contains the DHCP part of my local network:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes
DELAY=0
IPV6INIT=no
USERCTL=no
IPADDR=xx.yy.zz.aa
NETMASK=255.255.255.0
NM_CONTROLLED=no

Et voilà: The beast is running fine!
Thanks to all the blog posts which saved me many many hours!