SuSE 9 Paravirtualised Xen

From Granizada

This is a set of instructions about how to take a copy of data from an ancient production SuSE 9 i386 machine and recreate that machine in a Xen VM. This is no sort of recommendation about technology: I don't recommend any version of SuSE or Xen for any network unless it minimises disruption of existing infrastructure.

You have some choices:

• keep everything as-is: run full virtualisation, which is fine but requires some tuning under Xen. It also costs a lot more resources; you won't be able to fit nearly as many VMs on the same base hardware and they may run slower.
• make some modifications: run paravirtualised which while it has advantages requires a Linux 2.6 series kernel because Xen doesn't do version 2.4. SuSE 9 only comes with Linux 2.4, therefore some small changes are required.
• 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.

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.

Goal

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.

Basics

• allocate a DNS name for the new clone on the network
• create an ext3-formatted LVM the size of the source disk (we're not doing reiserfs, even though the SuSE 9 machines are all reiser. If you think reiser is a better way to go, adjust the following instructions accordingly. But be warned.) Round up to the nearest Gb unless you are very confident of what you're doing.
• Create a temporary Xen VM that has nothing to do (eg IP address) with the production system you're cloning. Make sure there is enough RAM for large rsyncs, you can always reduce the RAM afterwards (or destroy the VM entirely.) The reason we want this temporary VM is to run YaST in a chroot without risking the network. Note the careful use of YaST and risk in the same sentence. Unless you know YaST very well, including this old version, there is a chance that you will cause chaos on your network. You may want to work on an isolated network if you are concerned.
• attach the new ext3 LVM to the existing VM (either edit the .cfg or use xm attach. mkdir /target. mount.
• rsync -Wxva productionmachine:/ /target . -W since we know there is nothing on the destination. Add -z if you are doing this over a slow-ish link.
• mkdir /target; mount /target; chroot /target
• edit /etc/fstab and change "reiserfs" to "ext3"; also check what disks are used so they reflect the Xen .cfg file

You are now inside the cloned target and can start configuring.

You now need to choose the appropriate sections further down this page and follow the instructions there. Then return here.

Now:

• make sure you have the Xen 2.6.18 series kernels (as packaged in Ubuntu and Debian) not any later ones. These later kernels require configuration changes 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.
• cp 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 {VM}.cfg file contains the following "extra" line:

extra = 'vdso=0 devfs=nomount console=xvc0 xencons=tty'

• xm create {NEWVM}.cfg -c

The vdso parameter si described in various places as only applying to 32-bit base hardware. That is not correct, and 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.

How to run YaST the first time

You need to run YaSY in order to change network information to the clone details.

Always run YaST in a disconnected VM the first time you run it on the cloned image. That will stop bad things happening, depending on what the source VM was set up to do. After the first time it should be as safe as YaST ever is.

• 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 which minimises the damage.
• Out in dom0, fsck.ext3 /dev/{$LV DEVICE NAME}. At worst it 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

• 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. SuSE has a very clear idea that a GUI console is essential on every server :-)
• YaST: network hardware details - remove ethernet module to be tidy, because Xen ethernet is built into the kernel
• by default 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

Avoiding Network Madness

There's a good chance that your server has been configured to do some tasks that will cause trouble if a clone suddenly appears on the network. Here are some steps to consider that should mitigate this sort of problem. Reverse these when you want to take the system live.

The bigger point is that often it isn't known exactly what an old server does!

• backup /etc/sysconfig/network to [..]/real-$TARGET-network
• edit /etc/hosts so it only has correct information in it; a Xen VM install can create junk depending on the tools used to create the VM
• edit /etc/HOSTNAME so it has the correct (clone) name
• remove nameserver 127.0.0.1 from /etc/resolv.conf
• cd /etc/init.d; mv cron off.cron ; mv sendmail off.sendmail (or whatever MTA you use.)
• Stop very bad stuff happening if you have these services installed: cd /etc/init.d ; mv dhcpd off.dhcpd ; mv smb off.smb ; mv nmb off.nmb ; mv hylafax off.hylafax ; mv cups off.cups ; mv ldap off.ldap.
• any non-YaST network configuration, eg other ethernet aliases?
• rm /etc/network/routes* , many networks have complicated manual route settings (yast will recreate it for us if we put the right stuff in yast.) With SuSE 9.0 it seems there is an occasional bug with YaST where routes are incorrectly retained no matter what you say in the interface.
• Yast: add default route
• yast: advanced networking box, remove all routing
• yast: remove ip forwarding
• Make sure the mail queues and print spools are empty or you will cause network madness!: check /var/spool/mqueue, /var/spool/clientqueue and /var/spool/cups

LDAP as Present in SuSE 9

The LDAP client libraries shipped with SuSE9 couldn't do TLS. So if in moving to a virtual infrastructure you also want to integrate into a modern OpenLDAP environment you need to make changes.

Edit /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 to host ldapb.example.org (or ldapm, as appropriate)
4. add the line: rootbinddn cn=admin,dc=example,dc=org

Edit /etc/sendmail.cf and change the hardcoded hostname (in two places, search for the name of the server being cloned).