Archive for December, 2007|Monthly archive page

Installing a Linux HVM guest on Xen

This for Ubuntu 7.10, it will work even for other distros.


1. Install a Linux distribution(Ubuntu 7.10 codenamed ‘Gutsy Gibbon’) on the machine.
2. Boot into the Linux installed in 1 above.
3. Xen version used is 3.1.0 .Kindly note that xen-3.2-rc2 is available in the mercurial repos, it looks like by this month end we will have a final release of xen-3.2. Therefore, while downloading xen, please make sure you are downloading xen-3.1.0 and not xen-3.2 .[Because i worked with 3.1.0 for this howto :)]
4. A VT/SVM-enabled processor e.g Latest Intel Core2 Duo processors and AMD Athlon X2 ,Barcelona, phenom etc. It is worth mentioning that VT/SVM-enabled alone is not enough, you need a motherboard which supports VT/SVM extensions of the processor. To check if a processor is capable of supporting HVM guests do –
$ cat /proc/cpuinfo | grep vmx or grep svm

Any kind of output means it is a VT/SVM-enabled processor.
5. If BIOS has virtualization disabled, kindly enable it so that Xen can make use of it.
6. Enable virtualization as in 4 above before compiling Xen-3.1, else Xen cannot make use of the VT/SVM extensions.
7. Ubuntu by default runs in non-root mode.Anything which requires a root access can be run using sudo .e.g sudo vi /boot/grub/menu.lst .

Actual Procedure –

1. Install all the dependencies required for compilation of Xen-3.1.0 source, using apt-get/synaptic/yum/whatnot, viz
* GCC v3.4 or later
* GNU Make
* GNU Binutils
* Development install of zlib (e.g., zlib-dev)
* Development install of Python v2.3 or later (e.g., python-dev)
* Development install of curses (e.g., libncurses-dev)
* Development install of openssl (e.g., openssl-dev)
* Development install of x11 (e.g. xorg-x11-dev)
* bridge-utils package (/sbin/brctl)
* iproute package (/sbin/ip)
* hotplug or udev

*gettext, libstdc, g++.

2. Install xen-ioemu-3.1 from synaptic/apt-get.This package will install xen-3.1 hypervisor into /boot from Ubuntu repositories and will also update /boot/grub/menu.lst.This is important to avoid problem of configuration overwrites by Ubuntu repositories. If this step is carried out after installation of the Xen-3.0.1, we are at a risk of overwriting configuration files installed by vanilla xen-3.0.1 source by Ubuntu repository.
3. compile Xen-3.1.0 source, making sure that you build two kernels instead of a common one. In other words, build linux-2.6-xen0 and linux-2.6.xenU instead of linux-2.6-xen. This can be done by passing trivial argument(s) to the make at cmdline, viz. make world KERNELS=”linux-2.6-xen0 linux-2.6-xenU”.Kindly note that in case of confusion, exact help can be found in the README file found in the xen-3.1.0-src directory.
4. Also if machine is going to use more than 4GB of physical RAM on the machine,please make sure that you compile a PAE enabled Xen. This can also be done by passing trivial argument(s) to the make at cmdline, viz. add XEN_TARGET_X86_PAE=y to the make commandline given as example in 3 above. Please make note that PAE enabled xen is required only when you are building a 32-bit Xen hypervisor, else there is no need of passing this argument for 64-bit xen.
5. After compilation 3 main files worth taking note of , viz linux-2.6.18-xen0 , linux-2.6.18-xenU and xen-3.1.0.gz.
– xen-3.1.0.gz is the main Xen hypervisor binary.
– linux-2.6.18-xen0 is the domain0 kernel a.k.a the host kernel.
– linux-2.6.18-xenU is the domainU kernel a.k.a the guest kernel.
6. We can ignore the domainU kernel for this howto.
7. Remove the xen-3.1.0 hypervisor installed by the synaptic due to step 2 and install the built ELF binaries using make at cmdline.
8. make an initrd image for the domain0 kernel using mkinitramfs. Please don not use mkinitrd to avoid any surprises.
9. Delete the entries made by the xen-ioemu-3.1 package installed in 2 above in menu.lst.
10. Make a new entry in the /boot/grub/menu.lst for just now installed Xen-3.1 as per required.Same can be done using $update-grub , but for now we have been doing everything with hand. Please make sure that you make the entry after the line “Other Operating Systems” in menu.lst, so that update-grub does not create lots of stale entries on its own later. This will make the initial grub screen look uncluttered and clean too.
10. Make the default booting entry in menu.lst to be the Xen-3.1 and not the stock Ubuntu kernel.
11. Reboot and chances are booting kernel will crash or hang.
12. If this is the case reboot into the original Ubuntu kernel from boot up grub menu.
13. The main reason(s) for boot failure –
– sata disk drive’s module was not built in the xen by default.
– root filesystem type was not built statically into the kernel.
– Or in the unluckiest of the cases we have a bleeding edge hardware which is not supported by 2.6.18 linux kernel.[There is a non-trivial solution to that too, which we can ignore for this, more on this later.]
– There can be other reasons also, which can be safely ignore as of now.
14. To solve the problem stated in 13 above, kernel recompilation is required. Kernel to be compiled is domain0 kernel with the SATA controller module/component built statically into the kernel and same should be done for the root file system type(viz ext3 mostly). We can ignore recompiling domainU kernel here.
15. Make sure that driver for NIC(s) is/are compiled too, either statically into the kernel or as a module.
16. Enable and disable anything else in the kernel compilation config menu which may be required for proper functioning of the machine.
18. Build this configured domain0 kernel.
19. Install this configured domain0 kernel./
20. Optionally rebuild the initrd image(step 8).
21. IMPORTANT : Please do $ sudo mv /lib/tls /lib/tls.original .It is very very important to do this, else we may get problems running applications using TLS(thread local storage) libraries.
21. Reboot into xen-3.1.0.
22. Once into newly booted domain0, run xend(Xen Daemon) if it is not running.
23. Create two partitions using fdisk/sfdisk/cfdisk/gparted .[A reboot may be required to re read the new partition table].
23. Modify the configuration file(s) to boot from Fedora’s ISO image.Also make the parition on which domainU is required to be visible to HVM domainU. This can be done using configuration files.
24. Once configuration files are tailored as per needs, run the HVM domain(Fedora 8 domain here) using xm tool.e.g xm create f8.hvm .
25. check the status with xm list. A ‘r’ denotes running, ‘b’ blocked, ‘p’ paused etc.[‘r’ state is of importance here].
26. connect to the Fedora installation using vncviewer .
27. A vnc window will pop up, and Fedora installation on the disk parition can be completed as usual.
28. After completion poweroff the Fedora 8 domainU using xm.i.e xm shutdown f8(name of the domainU).
29. Modify the configuration file to not use the iso image but to boot from the physical partition, where fedora8 is installed now.
30. Start the f8 domainU using xm .
31. Connect to it using vncviewer as shown in 26.
32. Boot into installed fedora8 image and have fun.


Using Gmail with claws-mail

claws-mail is certainly worth looking if you do not want to wander in frenzy of procmail, fetchmail, ssmtp and mutt.

Pretty lightweight, fast and nice support for a *lot* of features. Plugins are really good stuff. Gives a lot of flexibility. Freedom from HTML disease is soothing.

Good thing is it is snappy too.Though looks a little slow while fetching and especially during sending messages. But overall a good GUI mail client. Better than bloated Evolution and thunderbird.

Git Vs Mercurial (Updated)

I have used Git at work and while working on linux kernel for more than one year now. Apart from this my work gives me an oppurutnity to work with the git’s close cousin Mercurial aka Hg.

My experiences with Git are good not at all bad i must admit. Initially the learning curve was huge for me, i must confess.But once i started getting used to the whole concept of Distributed SCMs it felt nice and easy and pretty logical to work in a distributed working mode.Though I insisted on using Git at work(..yes thats correct at work) for internal projects, i was faced with challenge of coming up with less muck ups and more smiling faces around. Sadly the reality bite count disappointed me.Most of the developers were spellbound on what git was doing and more importantly how?. Well others were really dumb to never able to understand Git. Looks like Git needs a minimum IQ level to understand its working principle and usage.Anyway whatever, once it was through atleast some of the developers were impressed with Git.I must also admit higher managment was skeptical and less of supportive…aah usual corporate stuff. I am enjoying using git every day.I am hooked to cheap branches, excellent merging capability, blazing fast speed and distributed nature. Some things which i felt were really commendable were the git-revert and hard resetting feature.Wow! i was able to undo a bad commit, which showed up after a lot of commits since faulty merge by the team. Branching is supercool and simple. Just a git-branch state-23-7-07 abe56ff12…. , and you have a pristine branch from the commit with id abe56ff12…. .Extremely handy. Seriously ,as Linus somewhere mentioned Git is more of a filesystem rather than a SCM tool.

Mercurial has been a pleasant surprise.Though, i had my share of problems using Hg after using Git for pretty everything i wrote at work and at home too.

Okay here is the updated entry, short answer Git is better than Mercurial, hands down. Only place when mercurial wins is ease of use for newcomers.But once you get over this happy feeling of easyness and start asking for more from mercurial, it falls down flat on its face. With all apologies to Matt Mackal and the wonderful team of Mercurial, I still find mercurial to be a little behind git. No doubt it is easy and fast. But git is more robust and rather mind boggling when it comes to saving a developers life.

I hope I am wrong here in my interpretations over mercurial but mercurial’s named branch support within one repository sucks big time. Perhaps I am doing it wrong because I come from git land(?). But it is a little clumsy to work with named branches in a single mercurial repository, unlike git where it is perfectly nice. hg revert disappointed me when working with mutiple named branches in same directory.

Well, still what i like about mercurial apart from ease of use and usually said stuff is, its hg export. It is nice and quite handy to generate a patch for my changesets. Hg is indeed a cool software which i like and use but still I think Hg can learn a thing of two from git and vice versa.