Simple Bugzilla client

At the moment I work as an IT Consultant on a QA-related project in Beijing at an outsourced partner. As you might know, the Internet connectivity in China is not optimal and this caused some issues on our end. Since we have to do a lot of cross-checking, we needed a way to keep track of remotely reported bugs and store these in a local instance of a previously in-house developed cross-check tracker. I started to develop a simple client to pull information from the remote Bugzilla instance which is then stored locally. This solved most of the issues we encountered with the latency and improved the productivity of our team.

XML-RPC client
The local tracker is built in PHP, so at first a small prototype was built to see if it was possible to call Bugzilla's XML-RPC interface. To ease the development I chose to use the standard ZendFramework library and the XML-RPC client they offer, Zend_XmlRpc_Client. The biggest issue I encountered was the way authentication was implemented on the remote side, but the actual client was simple and very easy to implement. The prototype was first done in a very sequential way... and eventually after a little bit of refactoring this is what remained:

// Add the AutoLoader
require_once('Zend/Loader/Autoloader.php');
Zend_Loader_Autoloader::getInstance();

class BugzillaClient
{
  // Initialize the client
  protected $rpcClient = null;
  protected $basUrl = null;

  public function __construct($baseUrl, $username, $password)
  {
       $this->baseUrl = $baseUrl;    // Store internal for later use
       $this->rpcClient = new Zend_XmlRpc_Client($baseUrl . "/xmlrpc.cgi");

       $httpClient = $this->rpcClient->getHttpClient();
       $httpClient->setCookieJar();  // Needed to retain user cookie
       $httpClient->setAuth($username, $password, Zend_Http_Client::AUTH_BASIC);

       // Login request (XMLRPC)
       $response = $this->rpcClient->call('User.login', array(array(
           'login'    => $username,
           'password' => $password,
           'remember' => 1
       )));
  }

  public function __destruct()
  {
       // Logout request (XMLRPC)
       $response = $this->rpcClient->call('User.logout', array());
  }

  public function Get($id)
  {
       $returnValue = array();

       // Get request (XMLRPC)
       $response = $this->rpcClient->call('Bug.get', array(array('ids' => $id)));
       $index = 0; // Only retrieving one bug, so don't bother with index now

       $returnValue['id'] = $id;
       // Construct a remote URL
       $returnValue['url'] = $this->baseUrl . "/show_bug.cgi?id=" . $id;
       // Collect some basic information about the bug
       $returnValue['summary'] = $response['bugs'][$index]['summary'];
       $returnValue['status'] = $response['bugs'][$index]['status'];
       $returnValue['resolution'] = $response['bugs'][$index]['resolution'];

       // Comments request (XMLRPC)
       $response = $this->rpcClient->call('Bug.comments', array(array('ids' => $id)));
       // Extract the first comment from the bug and store as description
       $returnValue['description'] = $response['bugs'][$id]['comments'][0]['text'];

       return $returnValue;
   }
}

This code provides a constructor which does the login and a 'Get' function to query the remote instance.

Example
To use this client you just need to include this module and create a new BugzillaClient instance.

require_once('config.php');          // Contains the baseUrl and credentials
require_once('BugzillaClient.php');  // This is the client code

$bzClient = new BugzillaClient($bzBaseUrl, $bzUsername, $bzPassword);
$bug = $bzClient->Get($id);

echo $bug['summary']);

After this the summary will be printed.

Future work
The last time I did some actual development with PHP was during PHP 3 and the move to PHP 4. At that moment I was not so happy with the Object Orientation model that the language offered. Luckily this improved a lot and hope this code testifies of that... as I have seen some horrific spaghetti code during these several days.

Using this solution does not provide a complete up-to-date picture of the bug, but this is not a problem to us. Besides, triggering a script which iterates over all local bugs and queries the remote state solved this issue. Some more features will be implemented, like searching for bugs and pushing comments back. This basic implementation code has been posted to public git repositories, so fork it and start pushing your improvements.

Repositories

• github
• gitorious

How-to setup dual-booting MeeGo 1.1 on the N900

The current image of MeeGo is for development purpose. Do NOT try to use it for daily use. You can make a phonecall or send a message, but I already had some issues with not being able to pick up phonecalls which I receive. It should be used as a means for developers to get familiar to the MeeGo environment for use on a handset. Also see the note at the end of this article.

For this how-to I use Fedora 13, but tmost of the steps also apply to any other Linux distribution. Be sure you have downloaded the correct MeeGo images before you begin and that you have a MicroSD card of 2G or more. I used a 4G MicroSD card from SanDisk.

The kernel root filesystem you download have to download from: http://repo.meego.com/MeeGo/releases/1.1/handset/images/meego-handset-armv7l-n900/

You need the following two files:
meego-handset-armv7l-n900-1.1-mmcblk0p.raw.bz2 (521M)
meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 (1.5M)

N900
Enable the extras-devel repo on your device and install from app-manager: uboot-pr13
or from the terminal with:

# root
$ apt-get install uboot-pr13


Be sure you have upgraded to PR1.3 before doing this. This is all that's needed on the mobile handset.

Workstation
On Fedora you have to install the uboot-tools to create a bootable kernel image. For writing the disk image I also included pv to have some progress indication. Install these tools with:

$ yum install uboot-tools pv cfdisk


Connect your N900 in Mass Storage mode with the MicroSD card inserted or use a multicard reader. As mentioned before, use a 2G or more MicroSD card to dump the raw image to. You have to find the correct device to use from e.g. the dmesg, replace sdX with the correct device. The command for this is:

$ bzcat meego-handset-armv7l-n900-1.1-mmcblk0p.raw.bz2 | pv | sudo dd bs=4096 of=/dev/sdX


Note: This may take some time, especially on the class of SD card you are using. I used just a class 2 4GB from SanDisk. Also be sure it is not mounted during this action. Some distributions use auto-mounting for Removable Media.

To make the MicroSD card usable for dual-booting you have to add a third partition. This might be a little more tricky if you haven't done this often. That is why you can use cfdisk.

$ cfdisk /dev/sdX


And add a new partition in the last freespace you see. The first is only 1.3MB, which is TOO small to contain the kernel image. Define it as a primary partition of 4MB (or full size). Take note of the device name. It should be sdX3.

Now create a FAT filesystem on the newly created partition. This is where your kernel needs to be placed.

$ mkfs.vfat /dev/sdX3


Now you need to prepare the kernel image for use on the SD card.

$ mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 -d meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 uImage


You would now have a file called uImage which you need to place in the FAT filesystem on /dev/sdX3. If you have difficulty creating the file, you can download it from here. Be sure you rename it to uImage. Temporarily mount it or reinsert the SD card so auto-mount can deal with it. Copy the uImage file to the root and unmount.

Now you could use this MicroSD to boot MeeGo 1.1. Try it out by powering off your N900 phone, remove the backcover and place the SD card. Be sure you have placed the backcover before you power on the device. If you don't do so, the root filesystem can not be mounted and the device will show a kernel panic.

External links

• Install root filesystem on external card
• U-Boot for N900
• MeeGo for Nokia N900

Note
I do not take any responsibility in you damaging your device or loosing data during the process. As I had mentioned, it is intended for development use and therefore I hope you have some basic understanding of what you are doing. If you have any question, please post them in the MeeGo Handset forum.

Fedora visits China (Beijing/Shanghai)

A lot of things have happened in China relating to Fedora; our MIPS port gained attention from Loongson and we made Fedora 13 available on our servers. Although it has not been mirrored yet to secondary.fedoraproject.org, you can already try it out. The other thing is about what Kaio and I have been busy with for the last half year, the Chinese Fedora Community!

It seems our efforts have not been unnoticed and the Fedora Community Architecture team sent Mel Chua to China. Yesterday she arrived in Beijing and we immediately started to discuss about our community and future activities and how to gain a more widespread acceptance of Open Source in China.

One of the things we immediately agreed upon was, luckily her explanation was less morbid, to 'Raptor-proof our community'. Our community is fragile when it comes to responsibilities and the load carried upon those shoulders. For this to succeed we would like you to propose people or yourself for a role within the community.

It would be ideal if some of you would step forward and become a regional ambassador who can represent key regions in China, like Shanghai, Hong Kong, etc. The workload for this is low and when we can balance it out it would even be minimal. You would take care of distributing Fedora swag, like t-shirts in your area.

This Raptor issue also troubles our MIPS port. Currently we have three members and of this only the lead role can be performed by someone else. We have a nice group of people around us, but we are always searching for new members. If you want to help with documenting or other activities, just get in touch. No, you don't need to be Chinese :-P. If you have a Yeeloong netbook and got tired or Mandriva, help us test and build third-party packages.

We would really like to know about Open Source activities happening all over China or maybe you have suggestions. If you want to discuss this with us, join #fedora-zh and mailinglist. Mel's agenda for this week is still open, so if you want to meet her in Shanghai, this is your chance.

Thanks to all the members of the Chinese Fedora Community!

Installing SELinux on Linode (CentOS profile)

Recently I signed up for a different VPS hosting partner as the one I was using had a dreadful latency when dealing with international connections. The new VPS at Linode I am using has good ping times, the control panel often does correctly what it should do, but the out-of-the-box CentOS profile was in my opinion not what I am used to.

RHEL and Fedora sys-admins know about SELinux and the pains and pleasures it can induce. If you are new to SELinux, be sure to read a little bit of background: SELinux for dummies and Dan Walsh's Blog. Or watch these videos recorded by Scott Dowdle: "SELinux demystified", "Intro to SELinux" Part 1, Part 2.

It seems Linode does not provide SELinux support with their provided kernel. I do not know what their motivation is. Maybe they want to relieve their support of troubling questions (to which I would say: permissive or enforcing=0) or maybe they just don't see the need. However after reading several reports on the web I am sure people want this functionality, but have been troubled by out-of-date resources about recompilation of the kernel to get the needed SELinux support and paravirtualization operations (pv_ops), setting up pv-grub, etc.

Well, things are now much simpler as RHEL/CentOS provides the needed pv_ops kernels. The only missing part is to setup grub and get SELinux going. In several steps I will explain what needs to be done.

Instructions
For these instructions I created a standard CentOS 5.5 (64bit) profile VPS using Linode's Dashboard option 'Deploy a distribution'. Start the node and from the console or ssh perform these steps.

1. Install grub
Grub is not installed on the base system. You will need to install the package, create some symlinks and an empty configuration file which you will need later.

# yum install grub
# mkdir /boot/grub
# cd /boot/grub/
# touch grub.conf
# ln -s ../boot/grub/grub.conf /etc/grub.conf
# ln -s ./grub.conf menu.lst

2. Install kernel with pv_ops
You will need to install a Xen enabled kernel which are provided by CentOS. But for some reason the xennet and xenblk are provided as modules and fail during startup. To solve this issue we create a new initrd which can load these. Be sure to specify your kernel version correctly. You will also need this later for Grub.

# yum install kernel-xen
# mkinitrd -v -f --with=ext3 --with=xennet --with=xenblk /boot/initrd-2.6.18-194.3.1.el5xen-custom.img 2.6.18-194.3.1.el5xen
# echo "devpts /dev/pts devpts defaults 0 0" > /etc/fstab

3. Edit grub.conf
To enable the new kernel, you need to add this to our empty grub.conf. Be sure to verify your version.

# vi /etc/grub.conf

The contents of the grub.conf are:

#boot=/dev/vxda
default=0
timeout=1
hiddenmenu
title CentOS
root (hd0)
kernel /boot/vmlinuz-2.6.18-194.3.1.el5xen ro root=/dev/xvda
initrd /boot/initrd-2.6.18-194.3.1.el5xen-custom.img
title CentOS (enforcing=0)
root (hd0)
kernel /boot/vmlinuz-2.6.18-194.3.1.el5xen ro root=/dev/xvda enforcing=0
initrd /boot/initrd-2.6.18-194.3.1.el5xen-custom.img

The above configuration will automatically boot to the default option which is a pv_ops kernel which has SELinux enabled. The second boot option is handy of you encounter some issues during the next step. If you are uncertain, you can uncomment the following lines, but this means the boot will be interrupted by grub and needs you to select the boot option from the lish console.

#default=0
#timeout=1

4. Install SELinux
Installing SELinux now is a breeze.

# yum install libselinux selinux-policy selinux-policy-targeted
# genhomedircon
# touch /.autorelabel
# shutdown -h now

Now you only need to set your node to use pv-grub to boot from the configuration profile. This is briefly explained in this article on the Linode Library. Boot up your node and allow some time for the relabeling. It might be wise to verify the progress from the lish console. If everything went well, the filesystem should have been been relabeled after a while and the system should operate 'as normal' ;-). You can verify the state of SELinux from ssh using the command sestatus.

There is however still one issue I have not resolved, as soon as the console is handled by mingetty, it seems the lish console does not properly handle this. It might be an issue to use xvc0 instead, but I see this as a minor problem and rather have SELinux enabled.If you have a fix, please let me know so I can improve these instructions.

Chinese Fedora Community and Fedora-MIPS Port

Currently I'm getting ready to move to Beijing (北京), China (中国) in June. While I am still looking for employment I have also been busy with assisting the Chinese Fedora Community (FZUG/中文用户组). As part of some our activities I will give presentations about Fedora and the community at the BeijingLUG. It is a growing community... but we are still looking for new users, ambassadors and contributors. We would also really like to work together with other other user groups in the APAC. If you are Chinese, in China or interested, drop by in our IRC channel #fedora-zh on freenode or get in touch with me (吉拉德, gbraad), Caius Chance (kaio) or Yuan Yijun (袁乙钧, bbbush). We are looking forward to seeing you!

Part of building the Fedora brand, some friends of the Chinese community and I started to port Fedora to the MIPS architecture. MIPS is an architecture that gained a lot of attention recently with the release of the Loongson processor. This processor is Chinese made and ended up in several netbooks and mini-pc's. While they were only available on the Chinese market, they are now being sold in America and Europe, e.g. by the Freedom Included initiative.

Currently we have chosen to target the Loongson 2F, but in time we will also support other MIPS-compatible processors. The primary goal of this project is to provide support for MIPS as a secondary architecture in Fedora. Just like the ARM port, our secondary goal is to enable derivative distributions based on the Fedora package collection and repository that are more suitably optimized for embedded and mobile use-cases. For this we want to work together with the Mini SIG as we can both benefit from this.

We now have a test build available of Fedora 12 (as n32 mipsel) which should be able to run on Qemu or MIPS-based hardware, like the Fuloong. While we are in the process of fixing some remaining build and technical issues and submitting the patches, you are invited to help us test this release. The Fuloong is currently the platform we build and test on ourselves. Be warned, expect to do some DIY especially since no documentation is available yet... and your mileage may vary.

The team currently consists of me (project-lead), FaiWong (technical lead, lazyfai) and XinZhen (co-lead, lonestar). If you want to contribute or donate hardware, please get in touch with us. More information can be found on the Fedora-MIPS wiki page, or just drop by in our IRC channel #fedora-mips on freenode.

Migrating from VMware to KVM

A lot of reports on the internet talk about the reduction of costs when you invest in virtualization. This is something I will certainly not deny after many years of experience with VMware Workstation, VMware Fusion, VMware GSX (now VMware Server) and VMware ESX and having implemented several high-availability setups using ESX. Even at home I had several whitebox servers with Virtual Center... until I migrated away to KVM. In this article I will explain the reason of the migration and how to perform it with an example. It is written towards people who currently run VMware GSX or VMware Server on Linux.

Motivation
It is undeniable that virtualization provide you with a lot of benefits; consolidation of servers will save you money. Maintaining your virtualized servers becomes a breeze, since they are all accessible from a single front-end. But implementing your environment on VMware comes at a price... even for the free version VMware Server; maintenance. You will still need to monitor your virtualization servers for performance and distribute your virtual machines among your servers or resource pools according to load. Although there are tools available to assist you, it is not the biggest issue.

VMware Server requires an additional operating system like Linux (or Windows). This introduces an added maintenance dependency; kernel modules which VMware uses need to be recompiled when the kernel gets updated. If a security exploit is found in the kernel, the virtualization host can be compromised and therefore jeopardize the continuity of your business. To prevent this, you update the kernel, but on reboot you notice that VMware does not start properly. On the command line you will need to perform a vmware-config.pl which build the modules. Unfortunately, your kernel headers are newer and either vmmon (virtual machine monitor) or vmnet (network component) does not build properly. Because of this, your whole infrastructure is offline until VMware provides new components or the release of the community patch package 'vmware-any-any'.

Users of VMware ESX will not have this issue, since the operating system and modules are provided in the form of the VMware's vmkernel. If a security update is needed, you only need to install an update. The previously mentioned issue  has happened to me often enough and I I wanted to have the same solution as ESX, but with the convenience of using Un*x/Linux experience for maintenance without the dependency of a third-party product. Since RHEL 5.4 this is provided as an enterprise supported solution; KVM, the Kernel-based Virtual Machine, once developed by Qumranet and now owned by RedHat. And by using CentOS this is available to everyone without too much trouble.

There are some differences between VMware and KVM. KVM is provided as part of the kernel, so any Linux distribution can provide it as part of their offering. KVM supports different formats for a virtual hard disk, while VMware only uses their own VMDK format. VMware can run in a full virtualized mode and is therefore suitable for older hardware. KVM needs a processor that provides VT-x (Intel) or AMD-V (AMD) to operate. VMware can run x86_64 guests on a i686 host, while KVM can not.

Because of this last reason, I had to reinstall CentOS on one of my systems, since it still ran an i686 version of CentOS 5.4 (on a Core2Duo E6600). This provides a good overview of what needs to be done to run KVM on CentOS.

Note: since KVM uses qemu to emulate any hardware you can also choose to use qemu without KVM as the hypervisor, but instead use the kqemu kernel module.

Installation

You will need to download an installation disc of CentOS 5.4. Prefer to use the x86_64 version; CentOS-5.4-x86_64-bin-DVD.iso. During the installation you can keep the default settings and when asked for the 'additional tasks' you will perform, do not select the 'Virtualization' option. After the installation finished, you will need to update the system to the latest updates.

From the reinstall I noticed a minor error in the CentOS 5.4 x86_64 installation. Due to installing openssl.i686 it also installed a lot of other standard i386-arch libraries. You can find out if you also have those packages installed as described in a earlier post. If you also want to remove those packages, perform the following command line option before continuing.

$ rpm -e `rpm -qa --qf '%{name}.%{ARCH}\n' |grep i386` openssl.i686

To update your system:

$ yum update

If your system is up-to-date, continue to install the needed packages for KVM and Virt-Manager.

$ yum install bridge-utils kvm kvm-qemu virt-manager virt-viewer python-virtinst

In later versions of CentOS it might suffice to issue the command "yum groupinstall 'Virtualization'", but currently this installs a Xen enabled kernel. According to the used processor, you can test to load the needed kernel module and start the libvirt daemon.

$ modprobe kvm
$ modprobe kvm-intel (or kvm-amd)
$ service libvirtd start

I normally use a different management workstation. And as an example I use a Fedora 12 installation to connect to the virtualization host (beibei). First from a tunneled connection to the host (with X11 forwarding).

$ ssh -X root@beibei
root@beibei's password: **************
# virt-manager

This will start the Virtual Machine Manager from which you can create new instances. You can of course use a Gnome desktop from the CentOS system to manage your virtual machines, but it pays off to try a seperate management workstation. This will allow you to try additional features, like live migrations between KVM virtualization servers.

This is all it needs to install KVM on a CentOS 5.4 installation. For an earlier version of CentOS, it is best to consult the wiki article about KVM.

Network settings
A default VMware Server installation will bridge the network card you have. You will probably want to have the same configuration for your KVM environment. For this you need standard Linux bridging utilities.

$ yum install bridge-utils

You only need to edit (or create) some network-scripts to make a bridge work.

$ vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:1a:2b:3c:4d:5e
ONBOOT=yes
BRIDGE=br0

And create the bridge

$ vi /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge

When you start the network again, you will have a br0 and eth0 device.

$ service network restart

You will now be able to select a bridged network card inside the KVM virtual machine configuration. If you have more network card, create a bridge per network card.

Converting the virtual disk files
For the migration part I choose a virtual machine who once began it's life as a physical machine; forum.survion.net. It is a Linux installation once based on FC3, got migrated to CentOS... and then ran as a VMware virtual machine.

The VMware virtual machine consists of one or more hard disk files, with the extension .vmdk and a description file, with the extension .vmx. A listing of server-forum.vmwarevm looks like:

[root@beibei server-forum.vmwarevm]# ls -al
total 29405144
drwxr-xr-x  2 root users        4096 Dec 12 20:53 .
drwxr-xr-x 21 root root         4096 Dec  9 17:32 ..
-rwxr-xr-x  1 root vmware       8684 Dec  7 21:09 nvram
-rw-------  1 root vmware          0 Jan  3  2009 Red Hat Linux.vmsd
-rwxr-xr-x  1 root vmware       2369 Dec  7 21:09 Red Hat Linux.vmx
-rw-r--r--  1 root vmware        268 Jan  3  2009 Red Hat Linux.vmxf
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 storage-f001.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:20 storage-f002.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:21 storage-f003.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:20 storage-f004.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 storage-f005.vmdk
-rw-r--r--  1 root vmware 2147221504 Aug 30 14:45 storage-f006.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 storage-f007.vmdk
-rw-r--r--  1 root vmware 2147221504 Oct 25 19:18 storage-f008.vmdk
-rw-r--r--  1 root vmware 2147221504 Nov 30 04:05 storage-f009.vmdk
-rw-r--r--  1 root vmware 2147221504 Nov 30 04:04 storage-f010.vmdk
-rw-r--r--  1 root vmware    2621440 Jul 23  2008 storage-f011.vmdk
-rw-r--r--  1 root vmware        749 Dec  7 21:11 storage.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f001.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f002.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f003.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f004.vmdk
-rw-r--r--  1 root vmware   17659904 Jul 23  2008 system-f005.vmdk
-rw-r--r--  1 root vmware        616 Dec  7 21:11 system.vmdk

As you can see, there are two hard disks (system and storage) and several other files. The hard disk as shown here is a fully allocated file which is divided up in seperate 2Gb files (handy for use on a FAT32 filesystem for portability). We have to convert it back into a monolithic file for use on KVM. Luckily KVM understands the monolithic VMDK file format, so we will choose this for interoperability. To convert the file you can use a VMware provided tool called vmware-vdiskmanager (includes with VMware products).

$ vmware-vdiskmanager -r system.vmdk -t 0 forum-system.img
$ vmware-vdiskmanager -r storage.vmdk -t 0 forum-storage.img

After this you will have two files that need to be copied to the in the images folder of libvirt on the virtualization host (/var/lib/libvirt/images/). You can do this using scp, ftp or mount an NFS export. From here we can create a virtual machine to connect these disk files to. Connect to the virtualization host and start the Virtual Machine Manager.

Create the Virtual Machine
Select localhost and create a new virtual machine using the context menu. Give it a unique name that identifies it easily for you, as I did: server-forum. If KVM is installed properly, you can only select "Full virtualized' from the Virtualization Method. Select the CPU architecture that fits your former VMware virtual machine and as the hypervisor: kvm.



On the 'Installation Method' page choose 'Network boot (PXE)' so you don't have to select a installation disk image.



On the 'Storage' page you deselect the 'Allocate entire virtual disk now' since we will not use the create virtual hard disk image. Beware; don't let the size become 0, since this way libvirt will not create the disk file and will fail to create the virtual machine.



On the 'Network' page you will probably want to select the bridged network card. This gives you the same functionality as VMware did as default option. On the 'Memory and CPU Allocation page' you can adjust the settings which are most close to your former virtual machine. After the summary the virtual machine will start automatically. Immediately issue a 'Force Off' as Shut down option. Now select the 'Hardware' tab.



Remove the 'Disk hda' and add new hardware of the type 'Storage' and select the system file from the storage location. If you have selected the file, you will see the correct size. Do the same of the other disks you have.



Be sure to change the boot device in the Boot options of this VM. Else it will try to start using Network (PXE) instead of the virtual hard disk.

Now everything should be ok to start the virtual machine.

Issues you might encounter
The conversion will probably not be without problems. For instance, I had a common issue with the kernel of the virtual machine. Due to a kernel panic it did not start properly. Fortunately tools are available to perform actions of the virtual hard disk files. One of those tools is guestfish. On CentOS and Fedora you can install this tool using:

$ yum install guestfish

For instance, I had to download a newer kernel and try to install this inside the virtual machine. The following commands show what I did:

$ guestfish
fs# add /var/lib/libvirt/images/forum-system.img
fs# run
Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
fs# mount /dev/sda2 /
fs# mount /dev/sda1 /boot
fs# upload /tmp/downloaded.rpm /tmp/kernel.rpm
fs# command "rpm -ivh /tmp/kernel.rpm"
fs# vi /boot/grub/grub.conf

These commands will add the forum-system.img to a qemu instance. Inside the qemu instance you will then mount the mountpoints, upload the kernel RPM from the local path to the tmp inside the filesystem. From here nothing special... and then it will issue a command inside qemu to install the kernel package. This command will run inside the filesystem as if it performed the command from the commandline. Finally I verify the grub configuration and change it if necessary. From here I was able to start the virtual machine without any errors.

Note: If you convert Windows virtual machines you might encounter more issues. Those conversion steps are outside the scope of this document, but are not impossible to perform.

Fedora 12
The latest release of Fedora includes many improvements which are virtualization related. If you want to try KVM on a workstation, you should definitely try Fedora 12.

Below here you can see virt-manager. The interface has changed a little. As you can see from the screenshot, it is connected to the local machine and two remote hosts. The console is shown from the remote host (using ssh and vnc). For this no additional configuration was needed.



It is easy to monitor the performance of a virtual machine using the Virtual Machine Manager. Here you can see the server-forum instance with an overview of CPU/Memory usage and Disk/Network activity.



Just a few days ago SPICE was released. This is an alternative to vnc to view the console of a virtual machine. It is target towards the use of a Virtual Desktop. More information about this can be found on the SPICE website. A how-to for Fedora 12 is available.

Maemo 5 SDK on Fedora 12

It is possible to install the Maemo 5 SDK (final) on Fedora 12. It only takes two minor edits to the installer script. You first need to make sure you have installed Xephyr. You can do so with the command:

$ yum install Xephyr


since the installer is not able to do so for other distributions than Ubuntu and debian. You can download the GUI installer script from Forum Nokia: Maemo 5 SDK.

In the file maemo-sdk-install-wizard_5.0.py you can change line 129 to

SB_PATH="/opt/scratchbox"


It is just optional. But to me this location feels more appropriate then '/scratchbox'. On my system it is linked to another location with other hardware and software development tools.

The current version of the script seems to fail on Fedora because of not being able to install scratchbox due to a missing path.

Change line 2311 to:

exec_cmd(sb_installer_fn + opt + "-s " + SB_PATH)


Change line 2351 to:

cmd = "%s -d -m %s -s %s" % (sdk_installer_fn, self.__sdk_inst_m_opt_arg, SB_PATH)


This includes the Scratchbox path during the command invocation. You can then install the SDK by running the script. It will handle the download of PyQT and sip itself.

After the install you can start Xephyr. However you can not use the -kb option:

$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &


The first start of af-sb-init.sh failed for me with a coredump and several segmentation faults. try to close the scratchbox environment and try again.

Note: I haven't tried it with SELinux as enforcing since I currently run my workstation as permissive. Discussion is possible on the Maemo developer's forum posting.