Bug 1029792

Summary: VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used
Product: [Retired] oVirt Reporter: Patrick Hurrelmann <redhat>
Component: vdsmAssignee: Dan Kenigsberg <danken>
Status: CLOSED NEXTRELEASE QA Contact: Haim <hateya>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3CC: abaron, acathrow, bazulay, herrold, iheim, mgoldboi, redhat, sbonazzo, yeylon
Target Milestone: ---Keywords: Patch
Target Release: 3.3.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: in ovirt-3.3.2 beta Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-02 17:52:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1027349    
Attachments:
Description Flags
Missing qemu version in webadmin
none
VDSM log (slightly sanitized)
none
full patch none

Description Patrick Hurrelmann 2013-11-13 08:43:10 UTC
Created attachment 823293 [details]
Missing qemu version in webadmin

Description of problem:

When qemu-kvm-rhev is installed, vdsm does not report the used qemu version in its capabilities and the version of qemu as shown in webadmin stays empty. For live-snaphots (and probably other features, too) qemu-kvm-rhev is the preferred version over plain qemu-kvm. VDSM for RHEV has a patch, that changes detection of qemu-kvm to qemu-kvm-rhev (patch: 0069-VDSM-should-return-qemu-kvm-parameters-by-getCaps-AP.patch). For oVirt there probably should be a more robust solution, that is able to detect both variations.

Version-Release number of selected component (if applicable):
any ovirt vdsm release

How reproducible:
always

Steps to Reproduce:
1. install new host with qemu-kvm-rhev and register it to the engine

Actual results:
qemu version is not reported in capabilties and not shown in webadmin

Expected results:
qemu version is reported in capabilties and shown in webadmin

Additional info:

Comment 1 Patrick Hurrelmann 2013-11-13 08:44:08 UTC
Created attachment 823294 [details]
VDSM log (slightly sanitized)

Comment 2 Patrick Hurrelmann 2013-11-13 08:58:51 UTC
Installed qemu packages on this host:

qemu-img-rhev.x86_64        2:0.12.1.2-2.355.0.1.el6.9
qemu-kvm-rhev.x86_64        2:0.12.1.2-2.355.0.1.el6.9
qemu-kvm-rhev-tools.x86_64  2:0.12.1.2-2.355.0.1.el6.9

Comment 3 Dan Kenigsberg 2013-11-13 11:12:07 UTC
Could you give more details about your configuration?
Are you using oVirt's Vdsm with rhev's qemu-kvm? Why? Mixing ovirt and rhev may have other issues.

Comment 4 Patrick Hurrelmann 2013-11-13 12:43:55 UTC
(In reply to Dan Kenigsberg from comment #3)
> Could you give more details about your configuration?
> Are you using oVirt's Vdsm with rhev's qemu-kvm? Why? Mixing ovirt and rhev
> may have other issues.

This is a CentOS 6.4 host with oVirt vdsm (latest 3.3.1 beta) and a rebuild of qemu-kvm (with rhev features enabled). RHEV qemu and base qemu are the basically same SRPM. They only differ in the way they are build. RHEV qemu has rhev=1 defined in its spec and enables more features. Lately there have been several discussions in the mailing list and the consensus was that qemu-kvm-rhev is preferred over the default qemu-kvm because it does not support e.g. live-snaphots.

Comment 5 Dan Kenigsberg 2013-11-13 13:22:17 UTC
It should be an easyfix. Could you verify the attached patch?

Comment 6 Patrick Hurrelmann 2013-11-13 16:31:00 UTC
Tested on 3.3.1 with a respin of vdsm 4.13.0-11 and patch applied, but in vdsm.log I see:

Thread-13::ERROR::2013-11-13 16:24:18,855::caps::353::root::(_getKeyPackages) 
Traceback (most recent call last):
  File "/usr/share/vdsm/caps.py", line 342, in _getKeyPackages
    mi = ts.dbMatch('name', KEY_PACKAGES[pkg]).next()
TypeError: unknown key type

http://gerrit.ovirt.org/#/c/19295/ is needed as a prerequisite. When applying gerrit 21226 together with 19295 it works fine.

Full patch that addresses this ticket is attached.

Comment 7 Patrick Hurrelmann 2013-11-13 16:31:25 UTC
Created attachment 823536 [details]
full patch

Comment 8 Patrick Hurrelmann 2013-11-13 17:18:28 UTC
should probably be delivered with 3.3.2