Currently there are two primary management interfaces for KVM; neither is official to the project. RedHat is using their own Python-based Virtual Machine Manager while there is also a Gnome KVM Manager (GKVM) which is written in C.
I use Ubuntu linux, and recently I wrote an article regarding making kvm work properly on Ubuntu Feisty. I left the issue of VM management tools for another article - this one - because the issue was substantially complicated. In fact, I had no idea how complicated it was.
GKVM
I went with GKVM, because it seemed simpler and more in line with GNOME, and I am a GNOME user and I prize consistency. I do have a lot of non-GNOME programs installed (not everything is available in a GTK variety) but I always try to do things the GNOME way. On Feisty, you will need to install the libgnomeui-dev package before you can build it. libgnomeui-dev has many dependencies which are also required, of course. After unpacking the archive, I changed to the resulting directory and issued the following commands:
./configure --prefix=/usr/local; make; sudo make install
This rapidly produced the GKVM executable and installed it in /usr/local/bin/gkvm as desired. Running the program actually managed to locate my running virtual machine and show me its CPU usage. GKVM also appeared in my "System Tools" group in the Applications menu, indicating that Ubuntu is smart enough to scan /usr/local/share/applications/ for new .desktop files (GNOME launchers.)
Unfortunately, gkvm has some very serious shortcomings that will prevent me from using it. It always runs the version of kvm for x86-64, which I could probably change easily enough. It also only runs VMs in the background, using VNC to connect to them. It does not detect your bit depth and always runs VNC in 8 bit mode (I am in 24/32 bit mode.) It has no facility for network settings and they must be made manually and the appropriate switches inserted into the config screen manually. Looks like it's time to take a look at virtual machine manager.
Virtual Machine Manager
I downloaded Virtual Machine Manager 0.3.1 source code, changed into the directory, and ran configure (./configure --prefix=/usr/local). The script informed me that pygtk-2.0 was missing. This meant that I needed the python-gtk2-dev package. After installing this package and its dependencies (with aptitude, so that the packages will be removed automatically later if it is appropriate) the configure command was successful. Attempting to build the package (make) produced an error as Python.h could not be located. On a hunch I installed the python-dev package, which solved this problem and allowed the make to complete. Doing a sudo make install installed the program into /usr/local.
Running virt-manager, however, produced an error claiming "ImportError: No module named libvirt". So we also need to install the python-libvirt package. Then I get "ImportError: No module named virtinst" which suggests that I will need the virtinst package as well. This is also provided on the virt-manager download page. No instructions are given, however, for installing it. I tried "sudo cp -R virtinst /usr/local/lib/python2.5/site-packages/" which worked okay. virtinst requires something called "urlgrabber" (Ubuntu Feisty package python-urlgrabber). This is the last package to be installed to run virt-manager.
The problem with all of this is that when you try to run virt-manager and select qemu as the hypervisor, you get the error "Unable to open connection to hypervisor 'qemu:///session'". It looks like I need a libvirt_qemud program to talk to qemu. I downloaded libvirt sources and went to build them, which required the libreadline-dev package (currently a virtual for libreadline5-dev - always use the virtual unless it says otherwise.) As usual I run configure with the flag --prefix=/usr/local so that I'm not installing things all over my filesystem. With this package installed, the build completes successfully. The make is as usual followed by a sudo make install. This placed libvirt_qemud into /usr/local/sbin.
Since I had to install libvirt manually into /usr/local, I removed the ordinary Ubuntu-managed version. Naturally, this will remove python-libvirt, but that is actually part of the libvirt library distribution and if you have installed libvirt from sources then you have it already. Now, running virt-manager and selecting the qemu hypervisor interface automatically runs libvirt_qemud and we get the program interface we're expecting. The system, however, does not seem to detect my kvm process which is already running.
Perhaps my VMs must begin virtualized in order to be managed by libvirt? I will try creating a new VM. Clicking the new button offers me a choice of architectures, for which only i686 offers the checkbox to "Enable kernel/hardware acceleration". It seems like kvm has been detected, but then I hit the forward button and get the message "Your hardware does not appear to support full virtualization. Only paravirtualized guests will be available on this hardware." Clicking "OK" dismisses the dialog and does not permit me to proceed.
At this point I am going to have to give up and perhaps file some bug reports. It has become clear that virt-manager is simply not ready for primetime. Perhaps it has redhat-specific tests in it? Or perhaps the failing is that of libvirt? Regardless, kvm is working nicely without management and the appropriate modules are installed. As is typical of Redhat's Open Source projects, documentation is poor to say the least. Their page for virt-manager doesn't even discuss the use of the qemu backend except to mention that it exists - but documentation in fact does not exist.
Conclusions
If you are not using RedHat, your only reasonable solution at this time is to use gkvm, which supports only a very limited range of features directly, leaving you to enter most of the details manually. While it is likely that the problems with virt-manager will be cleared up eventually, right now your best bet is to manage large numbers of virtual machines with gkvm, or if you only have one or two, to simply start them from shell scripts as desired.