Description of problem: Error starting domain: internal error Child process (LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,?) status unexpected: exit status 1 Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1050, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 510, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error Child process (LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,?) status unexpected: exit status 1 There is nothing useful in syslog and there are no AVC's associated with this. Version-Release number of selected component (if applicable): libvirt-0.9.6-4.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. Start any VM
This is failing while executing the basic "probe" command to figure out the version / capabilities of the qemu-kvm binary. What happens when you run: /usr/bin/qemu-kvm -device ? -device pci-assign,? -device virtio-blk-pci,? \ -device virtio-net-pci,? manually from a shell prompt?
I get the following: [root ~]# /usr/bin/qemu-kvm -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,? Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory No accelerator found!
Well, there's your problem :-) The kvm module isn't loaded. Try running "modprobe -i kvm-intel" (or kvm-amd, whichever is appropriate). If that solves your problem, you should look into why the kvm modules aren't loaded on your system. If it doesn't solve the problem, it's possible that virtualization is disabled in your bios. In the meantime, Dan Berrange points out that although libvirt can't make the guest run in this situation (since it has <domain type='kvm'/>, but kvm isn't available), we should still probably spit out a better error message, perhaps by doing a preliminary check to see if /dev/kvm exists.
Yeah, if it would output a message instead of a traceback, that would be helpful. But regarding the module not loading, I found this in syslog: Dec 11 20:24:34 centaur kernel: [ 7.867038] kvm: disable TXT in the BIOS or activate TXT before enabling KVM Dec 11 20:24:34 centaur kernel: [ 7.867041] kvm: disabled by bios The same system works fine running F14.
I pushed the following to upstream libvirt last week. The message logged when kvm isn't loaded is now: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules. I'm marking this as CLOSED UPSTREAM. If you think the problem is serious enough to backport, please reopen the bug and make a comment to that effect. ============================================== 32f63e912d3bef42a7fa70a0f2d5b04b98afe936 Author: Laine Stump <laine> Date: Mon Jan 9 14:54:14 2012 -0500 qemu: check for kvm availability before starting kvm guests This *kind of* addresses: https://bugzilla.redhat.com/show_bug.cgi?id=772395 (it doesn't eliminate the failure to start, but causes libvirt to give a better idea about the cause of the failure). If a guest uses a kvm emulator (e.g. /usr/bin/qemu-kvm) and the guest is started when kvm isn't available (either because virtualization is unavailable / has been disabled in the BIOS, or the kvm modules haven't been loaded for some reason), a semi-cryptic error message is logged: libvirtError: internal error Child process (LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -device ? -device pci-assign,? -device virtio-blk-pci,? -device virtio-net-pci,?) status unexpected: exit status 1 This patch notices at process start that a guest needs kvm, and checks for the presence of /dev/kvm (a reasonable indicator that kvm is available) before trying to execute the qemu binary. If kvm isn't available, a more useful error is logged.