opensuse 12.2 KVM broken: "Error: A hypervisor is not running."


I just upgraded from 12.1 to 12.2 on an x86_64 (intel core i7 cpu) laptop. I wanted to experiment some with KVM and setting up virtual machines. I’ve tried starting ‘vm-install’ both from the GUI and from the command line, and when I do so, I get the following error:

Error: A hypervisor is not running. For kvm, load the kvm kernel modules. If you want to run xen, reboot and load the xen kernel.

I checked what modules were loaded with lsmod | grep -i kvm, and only the kvm module shows up. The kvm-intel modules isn’t loaded. When I try to load it “by hand” with modprobe, I get this error

FATAL: Error inserting kvm_intel (/lib/modules/3.4.6-2.10-desktop/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported

The relevant part of the modules.dep file looks OK (to my eye at least). Here is the relevant part:
kernel/arch/x86/kvm/kvm-intel.ko: kernel/arch/x86/kvm/kvm.ko
kernel/arch/x86/kvm/kvm-amd.ko: kernel/arch/x86/kvm/kvm.ko

I googled, and there was only a a couple of posts from 2009 from the suse bugzilla site. It sounded like that ended up being a configuration error of some sort.

Anyway, I would greatly appreciate advice, guidance, help with being able to set up a KVM on my 12.2 distribution.

One last thing, when I used ‘virt-install’, I could get a VM created. This is the command line invocation:
virt-install --connect qemu:///system --name NoniusVM --ram 2048 --vcpus 2 --os-type linux --os-variant opensuse12 --cdrom /var/lib/libvirt/images/openSUSE-12.2-DVD-i586.iso --disk path=/var/lib/libvirt/images/kccd_vm.img,size=25,sparse=false --vnc --network network:default

However, the install seemed to hang when it was probing the system. I don’t know if the hang is related to the above problem.

Please help.



I am using VirtualBox myself which is working just fine under openSUSE 12.2, but I wonder if you visited the YaST / Virtualiztion / Install Hypervisor and Tools?

Thank You,

Yes, I have. I have installed and configured all the pieces (as far as I can tell).

So this is not a problem I know exists yet, but there was a problem under openSUSE 12.1 in which using systemd could cause the KVM to fail to work. In openSUSE 12.1 you could switch to SystemV, but not for sure about that or not now. Consider that openSUSE 12.2 is new and I have not heard about all of the possible application combinations under the new openSUSE version. I would ask if there was any reason you might not want to look at VirtualBox as well? You got to at least look at the following messages on this VM version:

I also had a lot of good info here to read:

Thank You,

I gave up on KVM and went with VirtualBox. Much easier to use.

Yes, you are very right, for now at least. That being said, there are some very serious fellas out there that want or need to use KVM. In such a case, you need to know a lot more about KVM and openSUSE may even require some customization to really work well with it. For the more casual user, VirtualBox seems to fit the bill for most of us, including me.

Thank You,

I didn’t have issues that I can remember with kvm and systemd under 12.1. I don’t seem to have major issues under 12.2 either. But I’m using my own method though, and I have no idea what to do and how to do with YaST hypervisor tools. I use basically the same method under Fedora, Ubuntu and ArchLinux. The libvirtd and virt-install versions might be slightly different (and support more or less os variants for guests) but my script takes care of that.

*If all you want or need is to install Windows guests, you can safely skip this post. I don’t offer Windows support (nor does vm-create). VirtualBox is good enough and probably better than kvm for running Windows guests. *

Here’s the method I use to install Linux and Unix guests. I updated vm-create and I’m still testing it under 12.2 now.

As root,

  • add and refresh my repo and install vmscripts:
$ su -l
# zypper ar [noparse][/noparse]](  PTA
# zypper --gpg-auto-import-keys refresh -r PTA
# zypper -n in vmscripts

  • install the following packages:
# zypper in virt-manager virt-viewer qemu kvm
  • enable the libvirtd service:
# systemctl enable libvirtd.service

When you reboot, libvirtd should be running:

# systemctl status libvirtd.service
libvirtd.service - Virtualization daemon
          Loaded: loaded (/lib/systemd/system/libvirtd.service; **enabled**)
          Active: **active (running) **since Thu, 20 Sep 2012 22:52:55 -0700; 6min ago
        Main PID: 3987 (libvirtd)
          CGroup: name=systemd:/system/libvirtd.service
                   3987 /usr/sbin/libvirtd --listen

Sep 20 22:52:56 gwynn libvirtd[3987]: 2012-09-21 05:52:56.306+0000: 4471: info : libvirt version:
Sep 20 22:52:56 gwynn libvirtd[3987]: 2012-09-21 05:52:56.306+0000: 4471: warning : virSecurityManagerNew:129 : Configured security driver "none" disables default policy to create confined guests

and kvm should be loaded. So on an AMD CPU, lsmod will show this:

# lsmod | grep kvm
kvm_amd                59609  0 
kvm                   447778  1 kvm_amd

and on an Intel CPU (from a 12.1 system) :

# lsmod | grep kvm
kvm_intel             141431  0 
kvm                   438869  1 kvm_intel

  • Next create a directory to store your virtual machines and another one to store the iso images.
    I’ll take /misc/vm and /misc/iso, because these are the defaults in vm-create. If you use other
    paths, you should set the value of IMGPATH and ISOPATH in /etc/vm-create.cfg accordingly.
# mkdir -p /misc/{vm,iso}
  • create a local storage pool for the virtual machines. It’s probably easier with a little script (Modify** vmpath**
    if needed):

#! /bin/bash
 -d $vmpath ] || mkdir -p $vmpath
if  -d $vmpath ] ; then
service libvirtd status &>/dev/null || service libvirtd start
cat > /tmp/default.xml << DEFAULTPOOL
<pool type='dir'>

if  -f /etc/libvirt/storage/default.xml ] ; then
	virsh -c qemu:///system pool-dumpxml default | grep -q $vmpath || {
	virsh -c qemu:///system pool-destroy default 2>/dev/null
	virsh -c qemu:///system pool-undefine default 2>/dev/null
	virsh -c qemu:///system pool-create /tmp/default.xml
	virsh -c qemu:///system pool-dumpxml default > /etc/libvirt/storage/default.xml
	echo "- creating default storage pool in $vmpath"
	mkdir -p /etc/libvirt/storage/autostart 2>/dev/null
	virsh -c qemu:///system pool-create /tmp/default.xml
	virsh -c qemu:///system pool-dumpxml default > /etc/libvirt/storage/default.xml
ln -sfn /etc/libvirt/storage/{default.xml,autostart/default.xml} 

If the script succeeds, it should print:

- creating default storage pool in /misc/vm
Pool default created from /tmp/default.xml

  • Set the IP of your gateway in the variable GW in /etc/vm-create.cfg:

# your gateway (unless set in the environment variable GATEWAY) 

Now you can create and run kvm virtual machines on your local hypervisor. Notice that vm-create can also install guests on remote hypervisors (using ssh, not tls - sorry).

# nat2bridge

assuming you want to use bridge. Don’t ask me how to use NAT, as I don’t.
When you’re done using the hypervisor and after you powered off the last virtual machine, you can remove the bridge with:

# bridge2nat

I don’t say it is the best way to do it. It’s just the way I do it.
You can check if the bridge is up with** ifconfig -a**

  • Finally a single command like the following one will create a virtual machine (called ‘olaf’) with a 10GiB virtual disk, 1 GiB of memory, sound support and install openSUSE 12.2 from network in it:
# vm-create -s 10 -S -b br0 -u opensuse olaf

If you want to see what this command does without actually doing anything, use the option** -t** ( or** --try**):

# vm-create **-t** -s 10 -S -b br0 -u opensuse olaf

--description="olaf (opensuse 12.2) - vm guest on host jadzia" 
--disk path=/misc/vm/olaf_hd0.img,size=10 
--network bridge=br0 

iso URL:

Use** vm-create -h** to see the different options and read this thread for more info: create kvm virtual machines](

  • Press escape to exit the splash screen and see what’s happening. Loading the installation may take some time.](

Der Rest ist Arbeit…

Et voilà!](

Now you can run** virt-manager** as user and double click on localhost(QEMU) to connect. Normal users need to provide root password. Alternately one could create a libvirt group and write a local policy. A polkit authentication agent needs to be running. It should be autostarted in /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop for Gnome, XDG, Xfce and in /usr/share/autostart/polkit-kde-authentication-agent-1.desktop for KDE. You might have to start /usr/lib/polkit-gnome-authentication-agent-1 (as user) for other desktops or put it in X startup scripts (xinitrc or Xsession) or init file of the window manager. For example, my icewm startup script looks like this:

# cat ~/.icewm/startup

( sleep 1 && ) &
**/usr/lib/polkit-gnome-authentication-agent-1 &**

If the polkit agent is not running, normal users will fail to connect to the hypervisor:

You know please_try_again, unless I have missed it, why not create a new article on this subject? I don’t have a problem if things are done outside of YaST as long as they work and any user could do it. Give it some though using what you have just posted here.

Thank You,

You know James, I guess I have a better idea. If you read the post, you’ll have noticed that it is not extremenly complicated after all, and you might already have understood the concept. So why don’t you give it a try and write an article or a blog article by coying/pasting anything useful from here? I see at least 3 advantages:

  • You will learn something
  • You will explain it better (from the user point of view)
  • I will fix something else in the meantime

And saying that, I just realized that I should set spice]( as display and qxl as video adapter (one can change that in virt-manager while the vm is not running). Then you can have the resolution you want in X. I’ll have to change the default in my script.

Actually I’m just installing and testing slowly everything (and different things). I read “KVM broken” and just wanted to make sure it is not. So don’t worry! It is not broken.

And of course, you do learn more by doing than just reading about it. However, I have found though that if you find a willing master on a subject, such as yourself, they can do a better job any day than some inexperienced dude from Texas could do, which is why I was volunteering you to do it. lol!

Thank You,

Yes, I understand … but I have sooo many things to fix. I could hire ten people, really. But I could not pay them. I wish someone would help me adding Grub 2.0 support to findgrub and fix my FreeNX build which doesn’t work with Gnome under 12.2 - right now, I have no idea why (I wouldn’t have notice if I hadn’t received emails).

And what about that stupid QT bug I mentioned in this other thread ( The VirtualBox interface is just unusable. I’m not kidding. At some point, it should be possible to use virt-manager with VBox machines (so you could administrate QEMU, XEN and VBox vms with the same tool and the same interface). I don’t know which version of libvirt exactly supports VirtualBox protocol. I have to check.

So one thing is for sure, I understand that a volunteer programmers job is never done. But, would we really have it any other way? The agony of the bug or a problem from a new update to the sweet smell of Victory when you get that bash script or what ever working again. And its great to get a good idea you have a good chance of making it work, but then again, I like to sit back every now and then and drink a cold one, as I am doing right now. I found a new beer called Indeo that I am liking a lot.

Making enough money and surviving the work week to be able to program again is a big enough task in its self. I have been working my a** off this last two weeks working out at the new F1 race track in Austin. The first such track in the US. So, I can say I have no problem with your effort and appreciate what it takes. Do what ever you can and do not worry about the rest.

Thank You,

Sometimes, virt-manager popups this misleading error message, the first time I start it

If I say “No”, it will just work fine (and I can connect to the hypervisor and create KVM guests locally*). I haven’t been able to reproduce this error consistantly. Restarting the daemon would just create new sockets, but still work. I thought that rebooting would allow me to reproduce the error, but not this time. Next time I see it, I will say “Yes” and see if it installs something.

  • well, to be honest, I should say that I don’t create KVM guests with the GUI interface. It just takes too long. That’s why I wrote vm-create. But I launch the vms from the GUI and I’m able to modify them (for example change the video adapter from vga to qxl and the display type from vnc to spice).

This time, I clicked on “Yes” and …

Error talking to PackageKit: org.freedesktop.DBus.Error.UnknownMethod: No such method 'InstallPackageNames' in interface 'org.freedesktop.PackageKit.Modify' at object path '/org/freedesktop/PackageKit' (signature 'iass')

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/", line 103, in check_packagekit
  File "/usr/share/virt-manager/virtManager/", line 135, in packagekit_install
  File "/usr/lib/python2.7/site-packages/dbus/", line 70, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/", line 145, in __call__
  File "/usr/lib/python2.7/site-packages/dbus/", line 651, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.Error.UnknownMethod: No such method 'InstallPackageNames' in interface 'org.freedesktop.PackageKit.Modify' at object path '/org/freedesktop/PackageKit' (signature 'iass')

Can anyone confirm that bug?

A maybe not entirely helpful suggestion

If virt-manager is having a problem, you might look into whether the “more Enterprise” OpenStack tools might have alternatives. SUSE and I assume therfore openSUSE is committed to fully participating as an OpenStack technology.

If the problem is more basic, eg a problem with libvirt that might be much harder to fix.


I noticed that virt-manager has just been updated to version 0.9.4-1.6.1. I will have to reboot to check if it’s fixed.

Another problem I notice is that Fedora 17 guests (both 64 and 32 bit) don’t boot (install successfully but won’t boot afterwards). ](

It could be a kernel bug in Fedora or a kvm bug. Don’t really have time to look at that closer.

on my waitlist. :frowning:

It seems to be fixed actually.