Bug 1229396

Michal, is this due to requirement on qemu-kvm-rhev targeted to RHEL 7.2?

No, this requires 7.1 whereas you're running 7.0 it seems
When does this happen?

It happens while adding the host RHEL7.1.z to an engine running on RHEL6.7 the qemu-kvm installed is the one coming from oVirt repository. 
qemu-kvm-ev-2.1.2-23.el7_1.3.1

I wonder what's the source package or compile options. Afaik rhel 7.1 qemu has 7.1 machine type. Can you doublecheck "qemu-kvm -M ?" output?

(In reply to Michal Skrivanek from comment #4)
> I wonder what's the source package or compile options. Afaik rhel 7.1 qemu
> has 7.1 machine type. Can you doublecheck "qemu-kvm -M ?" output?

Seriously, sometimes it seems you and I are working on different projects.
qemu-kvm-ev has been built from ftp://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/qemu-kvm-rhev-2.1.2-23.el7_1.3.src.rpm
It's in master snapshot since the VENOM vulnerability fix.


# /usr/libexec/qemu-kvm -M help
Supported machines are:
pc                   RHEL 7.1.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.1.0)
pc-i440fx-rhel7.1.0  RHEL 7.1.0 PC (i440FX + PIIX, 1996) (default)
pc-i440fx-rhel7.0.0  RHEL 7.0.0 PC (i440FX + PIIX, 1996)
rhel6.6.0            RHEL 6.6.0 PC
rhel6.5.0            RHEL 6.5.0 PC
rhel6.4.0            RHEL 6.4.0 PC
rhel6.3.0            RHEL 6.3.0 PC
rhel6.2.0            RHEL 6.2.0 PC
rhel6.1.0            RHEL 6.1.0 PC
rhel6.0.0            RHEL 6.0.0 PC
q35                  RHEL-7.1.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel7.1.0)
pc-q35-rhel7.1.0     RHEL-7.1.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.0.0     RHEL-7.0.0 PC (Q35 + ICH9, 2009)
none                 empty machine

it's VDSM which reports:

        emulatedMachines = ['pc',
                            'rhel6.6.0',
                            'pc-q35-rhel7.0.0',
                            'rhel6.4.0',
                            'q35',
                            'pc-i440fx-rhel7.0.0',
                            'rhel6.2.0',
                            'rhel6.1.0',
                            'rhel6.5.0',
                            'rhel6.0.0',
                            'rhel6.3.0']

# rpm -qv vdsm
vdsm-4.17.0-925.gitd18e2f1.el7.noarch

well, when things are odd and you're desperate you need to consider all crazy possibilities:-)

looks like vdsm bug!

well, actually a libvirt bug, but we better get a workaround asap

Workarounds: 
use after_get_caps hook and add 'pc-i440fx-rhel7.1.0' to the list of emulatedMachines list

(In reply to Michal Skrivanek from comment #9)
> Workarounds: 
> use after_get_caps hook and add 'pc-i440fx-rhel7.1.0' to the list of
> emulatedMachines list

just to make it easier:
create /usr/libexec/vdsm/hooks/after_get_caps/10_fakeemulatedmachine
the file must be readable and executable by vdsm

and add there:
import hooking
if __name__ == '__main__':
    caps = hooking.read_json()
    caps['emulatedMachines'].append('pc-i440fx-rhel7.1.0')
    hooking.write_json(caps)

you could test it with 
vdsClient -s 0 getVdsCaps
checking than the emulatedMachines field

ovirt-3.6.0-3 release

This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Hi Sandro,
Can you please provide the reproduction steps for the bug please?

(In reply to Nikolai Sednev from comment #13)
> Hi Sandro,
> Can you please provide the reproduction steps for the bug please?

Just deploy Hosted Engine. If it works, this bug has been verified.
Otherwise you'll have the error in bug description when it tries to spawn the VM.

Works for me on these components:
ovirt-vmconsole-host-1.0.1-0.0.master.20151105234454.git3e5d52e.el7.noarch
ovirt-release36-002-2.noarch
ovirt-engine-sdk-python-3.6.0.4-0.2.20151123.gita2f81ed.el7.centos.noarch
sanlock-3.2.4-1.el7.x86_64
ovirt-setup-lib-1.0.1-0.0.master.20151119123055.gitfa908be.el7.centos.noarch
qemu-kvm-rhev-2.3.0-31.el7_2.3.x86_64
ovirt-hosted-engine-ha-1.3.3-0.0.master.20151118145556.20151118145552.git71b535e.el7.noarch
ovirt-vmconsole-1.0.1-0.0.master.20151105234454.git3e5d52e.el7.noarch
ovirt-release36-snapshot-002-2.noarch
libvirt-client-1.2.17-13.el7.x86_64
ovirt-hosted-engine-setup-1.3.1-0.0.master.20151118143825.gitc013638.el7.centos.noarch
ovirt-host-deploy-1.4.2-0.0.master.20151122153544.gitfc808fc.el7.noarch
vdsm-4.17.10.1-0.el7ev.noarch
mom-0.5.1-2.el7.noarch

# /usr/libexec/qemu-kvm -M help
Supported machines are:
pc                   RHEL 7.2.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.2.0)
pc-i440fx-rhel7.2.0  RHEL 7.2.0 PC (i440FX + PIIX, 1996) (default)
pc-i440fx-rhel7.1.0  RHEL 7.1.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.0.0  RHEL 7.0.0 PC (i440FX + PIIX, 1996)
rhel6.6.0            RHEL 6.6.0 PC
rhel6.5.0            RHEL 6.5.0 PC
rhel6.4.0            RHEL 6.4.0 PC
rhel6.3.0            RHEL 6.3.0 PC
rhel6.2.0            RHEL 6.2.0 PC
rhel6.1.0            RHEL 6.1.0 PC
rhel6.0.0            RHEL 6.0.0 PC
q35                  RHEL-7.2.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel7.2.0)
pc-q35-rhel7.2.0     RHEL-7.2.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.1.0     RHEL-7.1.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.0.0     RHEL-7.0.0 PC (Q35 + ICH9, 2009)
none                 empty machine

Since oVirt 3.6.0 has been released, moving from verified to closed current release.

Hey Sandro, what is current release?
And what component is the fix?

I just opened this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1287299
And not sure how to treat it based on your bug.

Marina, the fixing package is qemu-kvm-rhev / qemu-kvm-ev >= 2.3.0.