Host hosted_engine_1 does not comply with the cluster Default emulated machines. The current cluster compatibility level supports [pc-i440fx-rhel7.1.0, pc-i440fx-2.1, pseries-rhel7.1.0] and the host emulated machines are 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.
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.