Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Non detection of qemu TCG mode support within a RHEL VM|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Pádraig Brady <pbrady>|
|Component:||libvirt||Assignee:||Jiri Denemark <jdenemar>|
|Status:||CLOSED ERRATA||QA Contact:||Virtualization Bugs <virt-bugs>|
|Version:||6.3||CC:||acathrow, berrange, dallan, dyasny, dyuan, jdenemar, mzhan, rwu, whuang, zpeng|
|Fixed In Version:||libvirt-0.10.0-0rc0.el6||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-02-21 02:11:49 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Pádraig Brady 2012-04-18 06:43:25 EDT
When running Openstack nova compute within a RHEL 6.3 VM, it fails with this error on startup: "Cannot find suitable emulator for x86_64". But we should be able to fall back to slower TCG mode. libguestfs (which doesn't use libvirt for detection) is able to start up its nested VMs fine, albeit slowly. This is with the latest libvirt-0.9.10-11.el6.x86_64 The handiest way to test is to run virt-manager. and you get the error: "Cannot find suitable emulator for x86_64". This work around from Daniel Berrange, allows one to start slower nested VMs (in TCG mode): ln -s /usr/libexec/qemu-kvm /usr/bin/qemu-system-x86_64 service libvirtd restart
Comment 2 Dave Allan 2012-04-23 16:40:27 EDT
I'm somewhat conflicted about this BZ, as unaccelerated qemu isn't supported in RHEL, so that would make this not a bug. OTOH, I'm personally in favor of allowing unaccelerated qemu, for exactly the situation you're in, so I'm not inclined to close this BZ too quickly.
Comment 5 Jiri Denemark 2012-07-16 05:50:32 EDT
Fixed upstream as v0.9.13-66-g8e6fb68: commit 8e6fb68f1ff224cdf1a4ed929fa92332fe533dec Author: Jiri Denemark <firstname.lastname@example.org> Date: Fri Jul 13 16:30:55 2012 +0200 qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
Comment 8 Jiri Denemark 2012-08-06 10:33:24 EDT
Steps to reproduce: 1. modprobe -r kvm_intel # or kvm_amd on AMD host 2. modprobe -r kvm 3. virsh capabilities With unfixed libvirt, the capabilities XML won't contain any <guest> element, while fixed libvirt will correctly report /usr/libexec/qemu-kvm is usable for creating qemu domains. The second issue can be reproduced with 0. make sure kvm_intel is properly loaded, i.e., undo steps 1 and 2 from the first test 1. mv /usr/libexec/qemu-kvm /usr/bin/qemu-system-x86_64 2. virsh capabilities Fixed version will report /usr/bin/qemu-system-x86_64 is usable for kvm domains. Unfixed version will only list qemu domain type. In other words, only fixed libvirt will put the following elements into capabilities XML: <domain type='kvm'> <emulator>/usr/bin/qemu-system-x86_64</emulator> </domain>
Comment 9 zhe peng 2012-08-06 22:52:25 EDT
Hi Jiri: Very thanks for your help! I can reproduce this with libvirt-0.9.13-3.el6.x86_64. verify with libvirt-0.10.0-0rc0.el6.x86_64 step: first point: 1: modprobe -r kvm_intel 2: modprobe -r kvm 3: virsh capabilities ...... <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine>rhel6.3.0</machine> ...... <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> ...... second point: 1:make sure kvm module loaded # lsmod | grep kvm kvm_intel 52890 0 kvm 314931 1 kvm_intel 2:# mv /usr/libexec/qemu-kvm /usr/bin/qemu-system-x86_64 3: virsh capabilities ....... <domain type='kvm'> <emulator>/usr/bin/qemu-system-x86_64</emulator> </domain> ....... verification passed.
Comment 10 errata-xmlrpc 2013-02-21 02:11:49 EST
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html