I am looking at using XEN to virtualize all of our test and development boxes at work. The newest versions of XEN along with the newest versions of Intel and AMD systems can handles Windows along with Linux. My plan is to start with Linux only to start and move on to Windows once this system is stable and makes people happy.
To do the initial testing I am using a personal machine running CentOS 4.4. It won’t be quick and will only handle one or two XEN instances but it will certainly get me the knowledge to get this into some sort of production run.
The Steps
- Check out the install guide
- Realize that CentOS 4.4 will not work. Download CentOS 5. Reinstall the server box with that version (thanks to kickstart and easy task)
- XEN is now a yum package. yum install xen (this installs 10 packages)
- Now for the kernel. yum install kernel-xen (just one package)
- Update GRUB; the yum install added the correct version to menu.lst, but the default boot needs to be changed to match (‘0’ in this case).
- Reboot and make sure xen is loaded (kernel and init.d process)
- XEN will start automagically after the reboot because of init scripts, run xm list to see Domain0 running – this is the host server
- Now the fun parts. These next couple of steps took me days off and on to get working. I, unfortunately, did not see this post by lyz until *after* I figured out these steps.
- Create a new initrd image. Use something like the command: mkinitrd -f –with=xennet –builtin=aic7xxx –builtin=serverworks –preload=xenblk –omit-raid-modules –omit-lvm-modules –fstab=/mnt/etc/fstab /boot/xen-initrd.img 2.6.18-8.1.1.el5xen Obviously you need to match your kernel version for the last argument. You can keep this file for any of the systems that are going to use this kernel as part of your guest XEN installs.
- Download the CentOS 4.4 base images from Jailtime.org. They are small and have very few things installed, but they work- and can be expanded to any size you need. The package includes a sample swap file as well.
- Create a xen config file for your installation. I created a script that will help me create custom images by mounting the img file from Jailtime and editing the network config and anything else I need customized. Here is a sample xen config file I am using:
kernel = "/boot/vmlinuz-2.6.18-8.1.1.el5xen"
ramdisk = "/boot/xen-initrd.img"
memory = 256
name = "fast-mc-1"
vif = [ '' ]
disk = ['file:/var/lib/xen/images/fast-mc-1.img,sda1,w', 'file:/var/lib/xen/images/fast-mc-1.swap.img,sda2,w']
root = "/dev/sda1 ro"
- Now start the image: xm create -c newxen.cfg
- The image should start but it will look like the console hung. You should be able to connect remotely via SSH. However- remote root login is not enabled. We need to fix console login and enable remote root via SSH (if that is wanted)
- Break the attached console: CTRL – ] then run xm shutdown guest-domain-name
- Mount the OS image: mount -o loop imagefile.img /mnt
- Change to the images dev directory (/mnt/dev)
- Use the host’s MAKEDEV to create some devices: /dev/MAKEDEV null zero random urandom console tty pty hda xvd loop
- Set the systems console to listen to xvc0 rather than tty2. This is located in /mnt/etc/inittab in the gettys section. I replaced the tty2 line with the following:
2:2345:respawn:/sbin/mingetty xvc0 - If you want to allow remote root SSH, edit /mnt/etc/ssh/sshd_config and set PermitRootLogin to yes
- If you could login when the system first came up, you would notice that nash-hotplug was taking up 100% CPU. This is not cool. You can fix that problem by adding a line to the end of /mnt/etc/rc.sysinit. The line I added was:
/usr/bin/killall nash-hotplug - Now unmount the image file and rerun xm create -c newxen.cfg
- The console should be up, the root login for the Jailtime images is ‘password’. Try both console and SSH login (if enabled). Everything should be good to go.
I hope someone who reads/found this entry gets some value out of it. Using this entry, lynema.com link above, and the xen install guide you should be able to get enough knowledge to get XEN working in your environment. As I expand my test lab (only two XEN hosts right now) I will have more details on customizing images and auto-loading them. The plan is to let Dev and QA create and destroy images on their own without having to rely on my hands on customization. It is a *long* way off, but this is a major step in the right direction.