Bug 483837

This error came up because hardware virt was not enabled on the host machine.  If hardware virt is not enabled KVM falls back to using the emulator which we explicitly remove from the Node since it is prerequisite that hardware virt is enabled.

The fix for this is to provide visual notification to end user that hardware virt is not enabled.

Perhaps we can as part of sysinit process (in ovirt-post perhaps) check for presence of cpu flags, kernel modules loaded, etc....  If hardware virt is not enabled then we can append something to /etc/issue and /etc/issue.net to give the user visual feedback that hardware virt is not present or enabled on the machine.

upstream patch to append to /etc/issue the warning about missing HW-assisted virt:
http://git.et.redhat.com/?p=ovirt-node.git;a=commit;h=2202fce01aa6daa19269596e15c55633856abf62

Using 1.0-1.snap5.2.el5ovirt I still get see the original error

[root@dhcp-100-19-45 log]# cat /etc/redhat-release 
Red Hat Enterprise Virtualization Hypervisor release 1.0 Beta (1.snap5.el5ovirt)
[root@dhcp-100-19-45 log]# virsh version
Compiled against library: libvir 0.5.1
Using library: libvir 0.5.1
Using API: QEMU 0.5.1
error: failed to get the hypervisor version


Howerver I can verify that the hardware enablement check put in to output an issue message with the login prompt if hardware virtualization is not enabled in the bios did work correctly on my machine.

libvirt doesn't even try /usr/bin/qemu-kvm

(In reply to comment #3)
> Using 1.0-1.snap5.2.el5ovirt I still get see the original error
> 
> [root@dhcp-100-19-45 log]# cat /etc/redhat-release 
> Red Hat Enterprise Virtualization Hypervisor release 1.0 Beta
> (1.snap5.el5ovirt)
> [root@dhcp-100-19-45 log]# virsh version
> Compiled against library: libvir 0.5.1
> Using library: libvir 0.5.1
> Using API: QEMU 0.5.1
> error: failed to get the hypervisor version
> 
> 
> Howerver I can verify that the hardware enablement check put in to output an
> issue message with the login prompt if hardware virtualization is not enabled
> in the bios did work correctly on my machine.  

Can you post the content of /etc/issue on the machine? Also, please post the content of /proc/cpuinfo for the machine for both with hardware virt enabled and with it disabled.

I checked out a box that mjenner left online for me.  The problem exists in libvirt0.5.1 and libvirt0.6.1 even with kvm enabled and the kmods loaded.  Talking to DV online he mentioned that there are differences between upstream libvirt and RHEL in terms of how the hypervisors/emulators are detected and there might need to be a RHEL specific patch to correct this issue.

Question is, should this even be a RHEV bug or is it a RHEL bug?  The end user will never run virsh version in RHEV.  In fact, libvirt is never even be used in RHEV1.0 except for by QE testing.  And this particular bug does not affect QE's ability to do testing of kvm functionality, correct?

I would move for moving this bug from RHEV to RHEL and flagging it as rhel-5.4?

The same issue with libvirt-0.6.1-1.fc10.x86_64 and only kvm-74-10.fc10.x86_64 installed (without qemu RPM)

Upstream fix
http://www.redhat.com/archives/libvir-list/2009-March/msg00281.html
was committed few days ago
http://git.et.redhat.com/?p=libvirt.git;a=commit;h=b1ca1e1c09b8f4924ee912cc0df4c7d4cbeca9e3

BTW it works with rawhide's qemu-system-x86 (which obsoletes kvm RPM) b/c that RPM contains both /usr/bin/qemu-kvm and /usr/bin/qemu-system-x86_64

Moving to RHEL since libvirt is not supported in RHEV1.0 production builds and this problem will need to be addressed in RHEL5.4 release

Fix merged upstream

That patch was actually included as part of the 0.6.3 rebase, so the fix
is in the current build,

Daniel

Verified with libvirt 0.6.3-6 on RHEL-5.4, already fixed.

[root@dhcp-66-70-85 ~]# virsh version
Compiled against library: libvir 0.6.3
Using library: libvir 0.6.3
Using API: QEMU 0.6.3
Running hypervisor: QEMU 0.9.1

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1269.html