Welcome to my world

Networking for KVM with CentOS 5.5

I've found numerous tutorials to set up KVM with CentOS 5.5. Some refer to the Red Hat guides, which are useless in my opinion if you are not using KVM in a large server park, others come up with scripts to set up networking.

I kept searching and trying configurations until I finally found one that works. Note that among problems you might encounter is the one that plagued me for months: CentOS is attempting to bring up the virtual device for LAN access on the host before bringing up the physical interface, this fails and prevents all networking and dependencies from starting properly.

To set up the bridge devices for KVM and the host (something which is done only once to 'wire' your virtual network instide the bridge) look here. Most of the guide is still relevant even if they refer to the Red Hat documentation (which is about Red Hats cloud virtualisation platform and not a single server running KVM).

Use a configuration like this for proper KVM networking under CentOS, Red Hat and probably even Fedora.

1. Edit /etc/sysconfig/network-scripts/ifcfg-eth0 to contain something like this:

# /etc/sysconfig/network-scripts/ifcfg-eth0 - the physical NIC which will not be used directly

The "NM_CONTROLLED" bit seems to originate from Fedora 12/13, CentOS might ignore it altogether so you could leave it out.

2. Edit /etc/sysconfig/network-scripts/ifcfg-br0 to restore network access for your host machine:

# /etc/sysconfig/network-scripts/ifcfg-br0 - Bridged network access for host

The crucial parts in this configuration is that eth0 is started on boot and is assigned a bridge device: 'br0'. The 'br0' device is marked as a bridge device which completes the dependencies between them. So make sure if you deviate from the examples you leave the types and 'bridge=br0' in tact.

Determining the UUID of a partition

From Wikipedia:

A Universally Unique Identifier (UUID) is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE).

The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts.

Since CentOS (and Ubuntu and others) use the UUID of partitions to mount or perform other operations on them, I needed to find the UUID of my storage partition. The downside to using UUIDs is obvious: I know the device name (/dev/sdb1) but I have no clue what the UUID of the partition is.

The upside is that if I move the drives around, so my /dev/sdb1 becomes /dev/sda1 for example, everything will still work because the identifiers remained unchanged.

Enough talking, I found 3 ways of finding the UUID of a drive on linux. Note that this is not all of them though, just enough for me.

Option 1: Use /dev

Since the UUID to device mapping needs to be done somewhere for the kernel and system tools, why not use that ourselves?

ls -l /dev/disk/by-uuid

Option 2: Use udev

The 'vol_id' program pulls the information from udev and presents it all in a fairly readable form. For some reason, my Ubuntu 10.10 does not have it anymore but possibly others still do.

vol_id /dev/sdb1

Option 3: Use blkid

The option I tend to use it to use the program called 'blkid'. Which as sole purpose (as its name suggests) is to show the block device ID of a block device *gasp*.

blkid /dev/sdb1

Converting sequential algorithms to parallel algorithms

Like I mentioned before, I started my thesis for my Computer Science degree. And without getting into too much detail at this point, one of the problems we are trying to tackle is the conversion from sequential programs to parallel programs.

The target architecture is not really of importance although we are stuffing it in a multi-core chip which is programmed into a Virtex 6 FPGA.

The thing that strikes me as odd is that an insane amount of work is being put into creating new applications for multi-core environments using tool-kits and various paradigms like tasks, task graphs, Khan Networks - whatever.

After years of development, the mainstream development tools come with tools to help the programmer to design multi-core programs without having to specify each and every thread and communication channels - a drawback which prevents most programmers to easily write parallel programs.

But most software these days is based on monolithic code meant to be running on a single core. Slowly parts are rewritten to exploit the surplus cores modern computers have but even then, most software scales poorly to more cores.

Since most 'fixes' involve a complete rewrite, this shift to actually write multi-threaded programs instead of having a hand full of manually designed partitions within a program to appear to be multi-core is finally beginning.

In a way, my research area is barely explored as I attempt to rewrite a decoder application to be converted from a single core program to something which can run on at least 8 cores... Hows that for multi-threading ^^...

New phonon-vlc backend for KDE 4

According to the devs of Amarok, the new VLC based backend for Phonon delivers better sound quality than the Xine backend. Something like this just begs to be explored of course and the instructions below are based on the generic ones but specifically for Gentoo. Please note that the backend is alpha: it is incomplete and changes daily.

Install VLC 1.1 pre by installing the live version (note that VLC 1.1 is about to be released any time now so this might be available by the time you read this). Note that I had to disable the Gentoo patches in the vlc-9999 ebuild as they prevent VLC from compiling.

ACCEPT_KEYWORDS=** emerge =vlc-9999

Note to self: add the keywords to the '/etc/portage/package.keywords' file. ;-)

Next, fetch the Phonon-VLC backend from GIT. Note that is should become 'stable' soonish (it said somewhere it should be moving to kdereview in the near future) so it should be safe to assume it sort of works.

cyberwizzard@cyberxps ~ $ mkdir kde

cyberwizzard@cyberxps ~ $ cd kde

cyberwizzard@cyberxps ~/kde $ mkdir src

cyberwizzard@cyberxps ~/kde $ cd src

cyberwizzard@cyberxps ~/kde/src $ git clone git://

Initialized empty Git repository in /home/cyberwizzard/kde/src/phonon-vlc/.git/

remote: Counting objects: 483, done.

remote: Compressing objects: 100% (400/400), done.

remote: Total 483 (delta 330), reused 116 (delta 66)

Receiving objects: 100% (483/483), 102.22 KiB, done.

Resolving deltas: 100% (330/330), done.

cyberwizzard@cyberxps ~/kde/src $ cd phonon-vlc/

cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ cmake -DCMAKE_BUILD_TYPE=debugfull -DCMAKE_INSTALL_PREFIX=/usr $HOME/kde/src/phonon-vlc/

...configure here...

cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ make

...wait a but more...

cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ su -c "make install"


[100%] Built target phonon_vlc

Install the project...

-- Install configuration: "debugfull"

-- Installing: /usr/lib/kde4/plugins/phonon_backend/

-- Set runtime path of "/usr/lib/kde4/plugins/phonon_backend/" to "/usr/lib:/usr/lib64/qt4"

-- Installing: /usr/share/kde4/services/phononbackends/vlc.desktop

cyberwizzard@cyberxps ~/kde/src/phonon-vlc $ su -c "kbuildsycoca4 --noincremental"

...password and lot of output here...

And thats it! Just fire up Amarok -> Settings -> Configure Amarok -> Playback -> Configure Phonon (or go through System Settings in KDE) and select the VLC backend (currently shows up as version 0.2).

Multi-monitor with KDE 4 and XRandR

One of the annoyances I've had with *nix so far was the apparent lack of multi-monitor control from the GUI. I've have experience with TwinView using xorg.conf, which worked fine but was quite a hassle to set up.

A side effect of this is the fact that once set up, I never touched the configuration again. For a computer with 2 screens hooked up permanently, this is fine. For a laptop which is dragged along and connected to beamers, TVs and monitors - not so much.

The good news is that I run a modern linux distro which led me to believe that the multi-monitor stuff should be enabled by default. However, I am not using Kubuntu (which would probably auto-enable all new toys for me) but rather I am using Gentoo. So it took some digging to figure out what is going on these days and how to use it. On a side note: you could use 'nvidia-settings' instead after plugging something in but I'd rather use the automatic method.

First a word of warning: the binary NVidia drivers do not support RandR 1.2. I have the 195.xx drivers installed and NVidia expressed back in 2007 that RandR 1.2 support was a 'priority' feature. One that apparently needed more than 3 years to be released. This means that using the binary 'nvidia' driver will give you RandR 1.1 which does not support the on-the-fly hotplug for displays. Instead you are forced to use TwinView, define meta-modes for every possible configuration and switch to those using 'xrandr' (or use the nvidia-settings tool each time).

Since this sort of defies having RandR 1.2 support altogether in Xorg, I decided to ditch the binary nvidia driver in favor of 'nouveau': the open-source replacement for 'nv' with decent 2D acceleration support (although I couldn't resist and enabled the highly experimental Gallium3D support as well).

To start off: trim down your Xorg configuration to a minimum, note that a recent Xorg is needed (I have 7.4 at the time of writing). This is needed to enable the auto-detection of many things or rather: manually specifying properties will override auto-detected settings and cripple Xorg's ability to handle everything on its own. As an example, I have included my own xorg.conf below.

Section "ServerLayout"

Identifier "Default Layout"

Screen 0 "Screen0"


Section "ServerFlags"

Option "AutoAddDevices" "true"

Option "AutoEnableDevices" "true"


Section "Device"

Identifier "nVidia_8600M_GS_nouveau"

Driver "nouveau"

Boardname "GeForce 8600M GS"


Section "Screen"

Identifier "Screen 0"

Device "nVidia_8600M_GS_nouveau"

Monitor "Monitor 0"

SubSection "Display"

Modes "1680x1050"



Section "Monitor"

Identifier "Monitor 0"

VendorName "Primary Monitor"

Option "DPMS"


Section "Extensions"

Option "Composite" "Enable"


The "ServerFlags" section is pretty simple: use every auto-detection known in Xorg to hotplug devices. This means both monitors and input devices like mouses and keyboards.

Next up are the 2 sections for my NVidia display card. Since I am using 'nouveau' instead of 'nvidia', make sure you are not loading "glx" somewhere (if you were using 'nvidia' in the past like me, you most likely have that somewhere).

The last 2 sections are fairly simple as well but note that I do specify the native resolution of my LCD screen as the preferred resolution.

Thats it! Restart your X server and run 'xrandr' so see the result. I plugged a VGA monitor in my notebook and this is the result:

cyberwizzard@cyberxps ~ $ xrandr 
Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 8192 x 8192
LVDS-1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1680x1050      60.0*+   60.0 
   1400x1050      60.0 
   1280x1024      59.9 
   1280x960       59.9 
   1152x864       60.0 
   1024x768       59.9 
   800x600        59.9 
   640x480        59.4 
   720x400        59.6 
   640x400        60.0 
   640x350        59.8 
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-1 connected 1280x1024+1680+0 (normal left inverted right x axis y axis) 312mm x 234mm
   1680x1050      74.9 +   60.0 
   1280x1024      85.0*+   75.0     60.0 
   1792x1344      60.0 
   1920x1200      59.9 
   1600x1200      75.0     70.0     65.0     60.0 
   1400x1050      85.0     74.9     60.0 
   1440x900       84.8     75.0     59.9 
   1280x960       85.0     60.0 
   1360x768       60.0 
   1280x800       84.9     74.9     59.8 
   1152x864       75.0 
   1280x768       84.8     74.9     59.9 
   1024x768      100.0     85.0     75.1     75.0     70.1     60.0     43.5     43.5 
   832x624        74.6 
   800x600        85.1     72.2     75.0     60.3     56.2 
   848x480        60.0 
   640x480        85.0     75.0     72.8     72.8     66.7     60.0     59.9 
   720x400        85.0     87.8     70.1 
   640x400        85.1 
   640x350        85.1