SuSE 9 Paravirtualised Xen

From Granizada

Jump to: navigation, search
This is a set of instructions about how to take a copy of data and programs from an ancient and production SuSE 9 i386 machine and recreate that machine in a Xen VM. It is the sort of thing that should be done if the machine is a hairball, my term for a system that has had so many undocumented things done to it that attempting to re-engineer the business logic would be pointless, expensive and error-prone. This article is no sort of recommendation about technology: I don't recommend SuSE9 or any version of Xen for any network unless it minimises disruption to existing infrastructure. SuSE9 was not designed to work with virtualisation, but with a little tweaking it will do so.

With Xen, the choices are:

  • Run full virtualisation (HVM mode), which lets you run the SuSE 9 disk image as-is. HVM works well but does require some initial Xen tuning and testing. This will also require more hardware resources. If you currently only run paravirtualised machines that is also configuration management overhead.
  • Run paravirtualised, which requires a few changes. This is more efficient and faster to boot, and there will be fewer virtual hardware problems simply because the target kernel is modified to know it is running virtualised. Usually there are only a few changes required to go paravirtualised, but SuSE9 is Linux kernel 2.4 and there is no version of a Xen guest for Linux 2.4.
  • don't use SuSE, rebuild your server. You need to balance the risk and cost of a from-scratch installation into a modern virtualised set of servers against the safety of moving a working and possibly very complicated and unmaintainable old server without functional change.
  • don't use Xen, pick an alternative virtualisation system. kvm is my preferred, however there are at least five alternatives that could do the job. Xen is probably not a good choice for a brand-new installation, however it is likely to be supported to commercial standards for some time to come although its demise seems very likely. If you have Xen already -- and as recently as early 2007 Xen was the most commercially deployable solution -- there is no reason why you should not continue.

Those are the choices. I chose to go paravirtualised. The rest of this article only relates to a paravirtalised VM.

These instructions are only tested on a paravirtalised Xen VM, although much of this will apply to other systems and even upgrading to Linux 2.6 on real hardware.

There is also consideration given to how to virtualise a machine on a production network. This is generic across any virtual system.



To create a virtualised clone of a production system on a network, so that the clone is available on the network and can be compared with the production system before changing over. Depending on the role of the server it might be wise to run in parallel for a while.


  • allocate a DNS name for the new clone machine
  • create and format an LVM the size of the source disk (SuSE9 uses reiserfs by default, but this in an opportunity to fix that transparently to any VM that doesn't rely on the reiser-specific sort order of directories. You can leave it as reiserfs without penalty.) Round up to the nearest Gb.
  • Create a temporary VM just for the conversion task. Make sure there is enough RAM for large rsyncs. This VM will be destroyed as soon as the job is done. The reason we want this VM is to run YaST without risking your network. I'm assuming here that you regard YaST on a neglected SuSE machine as being a dangerous beast.
  • attach the newly formatted volume to the existing VM (either edit the .cfg or use xm attach. mkdir /target. mount within the VM.)
  • (Within temporary VM) rsync -Wxva Source-SuSE-VM:/ /target . -W since we know there is nothing on the destination. Add -z if you are doing this over a slow-ish link.
  • (Within temporary VM) mkdir /target; mount /target; chroot /target
  • (Within chroot on temporary VM) edit /etc/fstab to change "reiserfs" to "ext3" if you decided to make this change; also check the names of disks to reflect the Xen cfg file. If you have applications that really do rely on specific device names you can create aliases. Remove all /dev/cdrom, /dev/dvd, /dev/fd0 etc devices in case some piece of software tries to access them and gets a surprising answer.

How to run YaST the first time

You will probably need to run YaST at least once, as described later in this document, even if you don't normally use YaST. When you do, it is very important that you run YaST in a disconnected VM the first time you start it on the cloned image. After the first time it should be no higher risk than YaST on SuSE9 ever is, although you may decide to be cautious.

Here are the steps to running YaST disconnected:

  • shutdown the temporary VM, remove "[vif]" line from .cfg, "xm create $VM -c". You now have a console login to a disconnected VM.
  • mount /target ; chroot /target; yast
  • .... do whatever you need to do in YaST as per later sections in this document ....
  • Exit yast, exit chroot. Yast will still have all sorts of files open on /target, but 'shutdown -h now' will mount it read-only to minimise the damage.
  • Out in dom0, fsck.ext3 /dev/{$LV DEVICE NAME}. At worst should just say "replaying journal".

Upgrading SuSE 9.0 to kernel 2.6 Xen

This has nothing to do with YaST, any SuSE 9 system faces the same issues when a kernel upgrade is forced. You can use networking for this step, so switch it back on in the Xen VM config file. As noted elsewhere, you must use a Xen kernel dating from 2.6.18 not later, because the SuSE 9 udev package can't cope with later kernel versions according to testing so far.

The following assumes a SuSE 9 DVD is available under /suse9.0_dvd.

  • cd /lib/modules; scp -r {$ANY VM}:/lib/modules/*xen* .
  • generate-modprobe.conf | tee /etc/modprobe.conf (for 2.6 kernel)
  • mkdir /sys
  • mknod /dev/xvc0 c 25 187
  • ln -s /bin/true /sbin/fsck.ext3. What we should really do is install a more modern version of ext2-tools [check]. But this stops the boot scripts wanting to do an fsck, and means fscks have to be done outside this VM for now. Temporary fix.
  • rpm -iv /suse9.0_dvd/suse/i586/udev-0.2-25.i586.rpm
  • ln -sv /sbin/udev /etc/hotplug.d/default/udev.hotplug
  • mkdir /dev/fd
  • edit /etc/init.d/boot.proc ; add: ln -s /proc/self/fd /dev/fd . Immediately after "start)" For 2.6 udev.
  • edit /etc/init.d/boot . Insert mkdir /dev/pts immediately before pts mount.
  • (may have to install i586/modutils-2.4.25-78.i586.rpm but I really don't think so. Just kept here as a placeholder for the moment; let me know if you find out first!)

General Incompatibilities

Not all of these incompatibilities and risks will apply to every site, but do read through them all carefully first.

The following fixes make SuSE9 boot cleanly in paravirt Xen, while making the absolute minimum number of changes to the working system:

  • cd /etc/init.d; mv kbd off.kbd
  • [Optional] Disable kdm and other X stuff. Not essential, but unlikely to be of any use here although you can make it work if you want. Disable by mv commands in /etc/init.d, eg 'mv kdm off.kdm'.
  • YaST: Go into network hardware, change address and hostname.
  • YaST: network hardware details - remove ethernet module
  • edit /etc/HOSTNAME so it has the correct (new, virtual) name
  • udev does not correctly run at boot time, to set initial permissions on /dev; add the following to /etc/init.d/boot.local:
chmod 666 /dev/null /dev/zero
chmod 664 /dev/random /dev/urandom

Are you worried about what might happen when you bring this machine up? In which case maybe:

  • before running YaST, backup /etc/sysconfig/network to [..]/real-network in case there are routes or other information that may get lost (or cause trouble.)
  • before running YaST, edit /etc/init.d/network, comment out any ethernet aliases, ie things like "ifconfig eth0:0"
  • Typical services that cause trouble in a cloned machine:
cd /etc/init.d;
for serv in cron sendmail cups dhcpd smb nmb kbd ldap named nmb 
do mv $serv off.$serv

Is the cloned server running Sendmail? If yes, edit /etc/ and change the hardcoded hostname (in two places, search for the name of the server being cloned).

Was the cloned machine also a router? In which case maybe run the following from 'xm console':

  • YaST: add default route
  • YaST: advanced networking box, remove all routing
  • YaST: remove ip forwarding

Does the clone target need to talk to some other LDAP server than SuSE9 for authentication? In which case you need to change the very old OpenLDAP configuration on SuSE9 in both /etc/ldap.conf and /etc/openldap/ldap.conf:

  1. comment out any line which starts with tls_ or ssl
  2. add the line: ssl off
  3. change the "host" line (see below)
  4. add the line: rootbinddn cn=admin,dc=example,dc=com,dc=br

The "host" line in both /etc/ldap.conf and /etc/openldap/ldap.conf lists the two nearest servers, for example:

  • host

Make sure the mail queues and print spools are empty: check /var/spool/mqueue, /var/spool/clientqueue and /var/spool/cups

All Done

  • make sure you have the Xen 2.6.18 series kernels (as packaged in 32-bit Ubuntu and Debian servers) not any later ones. These later kernels require even more configuration changes than described in this article to make the SuSE9 udev package work, more likely replacing it altogether, and the only way to avoid doing this work is to use an older 2.6 kernel.
  • copy the corresponding 2.6.18 kernel modules into /lib/modules in the VM
  • cp an existing close /etc/xen/domains/{VM}.cfg or create one from scratch
  • make sure the {NEWVM}.cfg file contains the following "extra" line:
extra = 'vdso=0 devfs=nomount console=xvc0 xencons=tty'
  • xm create {NEWVM}.cfg -c

Job done. You can now ssh to the clone IP address.

The vdso parameter is incorrectly described in various places as only applying to 32-bit base hardware. No! without it your SuSE VM will fail on boot with a spectacular and obscure error in the loader library. devfs is important because we're using udev instead.

JOB FINISHED. You can now ssh to the clone IP address.

Personal tools