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:
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:
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.
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.
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*.
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 ^^...
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.
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 ~ $ cd kde
cyberwizzard@cyberxps ~/kde $ mkdir src
cyberwizzard@cyberxps ~/kde $ cd src
cyberwizzard@cyberxps ~/kde/src $ git clone git://gitorious.org/phonon/phonon-vlc.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/
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/phonon_vlc.so
-- Set runtime path of "/usr/lib/kde4/plugins/phonon_backend/phonon_vlc.so" 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).
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.
Identifier "Default Layout"
Screen 0 "Screen0"
Option "AutoAddDevices" "true"
Option "AutoEnableDevices" "true"
Boardname "GeForce 8600M GS"
Identifier "Screen 0"
Monitor "Monitor 0"
Identifier "Monitor 0"
VendorName "Primary Monitor"
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: