Bug 1287126

engin.log shows the following line:

2015-12-01 15:44:25,054 WARN  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-65) [17d97417] Correlation ID: 17d97417, Job ID: 567a69a9-8767-4d51-af09-76ac6dd0849f, Call Stack: null, Custom Event ID: -1, Message: Host ovirt1 does not comply with the cluster Default emulated machines. The current cluster compatibility level supports [pc-i440fx-rhel7.2.0, pseries-rhel7.2.0] and the host emulated machines are pc-i440fx-rhel7.1.0,rhel6.3.0,q35,rhel6.1.0,rhel6.6.0,rhel6.2.0,pc,pc-q35-rhel7.1.0,pc-q35-rhel7.0.0,rhel6.4.0,rhel6.0.0,rhel6.5.0,pc-i440fx-rhel7.0.0.


Deploying hosted_engine stops at:
          Checking for oVirt-Engine status at ovirt.satellite.local...
[ INFO  ] Engine replied: DB Up!Welcome to Health Status!
[ INFO  ] Connecting to the Engine
          Enter the name of the cluster to which you want to add the host (Default) [Default]: 
[ INFO  ] Waiting for the host to become operational in the engine. This may take several minutes...
          The host ovirt1 is in non-operational state.
          Please try to activate it via the engine webadmin UI.
          Retry checking host status or ignore this and continue (Retry, Ignore)[Retry]? 


In case the DC and Cluster compatibility is set to 3.5 the host can be added.

Sorry too fast submitted.
After updating the DC and cluster to 3.6 the host stays up. But as soon as the Host is set to maintenance and tried to enable again, the host also goes to Non Operational.

Could it be that we're still missing bug 1210050 ?

*** Bug 1287299 has been marked as a duplicate of this bug. ***

The released content doesn't correspond to what should be out there. Please check qemu-kvm-rhev version, it is likely an old 7.1-based one

note as per Fabian RHEV-H should work ok as it does include the right set of packages

Hi Martin, if needed, there is a workaround available - at the end of the description of this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1287299#c0

(In reply to Michal Skrivanek from comment #5)
> The released content doesn't correspond to what should be out there. Please
> check qemu-kvm-rhev version, it is likely an old 7.1-based one

Indeed, this is what I see on my machine:
~~~
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-2.1.2-23.el7_1.10.x86_64
~~~

However, I do not see why this should be a problem and why we just cannot update the default list of emulated machines on the engine to include the rhel7.1? (unless it is not a static list and actually generated on the fly, I do not believe it is.)

Hi Marina,

(In reply to Marina from comment #9)
> (In reply to Michal Skrivanek from comment #5)
> > The released content doesn't correspond to what should be out there. Please
> > check qemu-kvm-rhev version, it is likely an old 7.1-based one
> 
> Indeed, this is what I see on my machine:
> ~~~
> # rpm -q qemu-kvm-rhev
> qemu-kvm-rhev-2.1.2-23.el7_1.10.x86_64
> ~~~
> 
> However, I do not see why this should be a problem and why we just cannot
> update the default list of emulated machines on the engine to include the
> rhel7.1? (unless it is not a static list and actually generated on the fly,
> I do not believe it is.)

no it isn't. It is taken from the database table vdc_options:

engine=# select * from vdc_options where option_name='ClusterEmulatedMachines';
 option_id |       option_name       |             option_value              | version 
-----------+-------------------------+---------------------------------------+---------
        40 | ClusterEmulatedMachines | rhel6.2.0                             | 3.0
        41 | ClusterEmulatedMachines | rhel6.3.0                             | 3.1
        42 | ClusterEmulatedMachines | rhel6.4.0                             | 3.2
        43 | ClusterEmulatedMachines | rhel6.5.0                             | 3.3
        44 | ClusterEmulatedMachines | rhel6.5.0,pseries                     | 3.4
        45 | ClusterEmulatedMachines | rhel6.5.0,pseries                     | 3.5
        46 | ClusterEmulatedMachines | pc-i440fx-rhel7.2.0,pseries-rhel7.2.0 | 3.6
 (7 rows)


So one can easily change it also by running an update on the table:
engine=# update vdc_options set option_value='rhel6.5.0,pseries' where option_id=46;

Cheers,
Martin

(In reply to Marina from comment #9)
> (In reply to Michal Skrivanek from comment #5)
> > The released content doesn't correspond to what should be out there. Please
> > check qemu-kvm-rhev version, it is likely an old 7.1-based one
> 
> Indeed, this is what I see on my machine:
> ~~~
> # rpm -q qemu-kvm-rhev
> qemu-kvm-rhev-2.1.2-23.el7_1.10.x86_64
> ~~~
> 
> However, I do not see why this should be a problem and why we just cannot
> update the default list of emulated machines on the engine to include the
> rhel7.1? (unless it is not a static list and actually generated on the fly,
> I do not believe it is.)

Please don't do that. It will allow you to add the host all right, but you are running a _wrong_ QEMU, the one not supporting fully the 3.6 features (notably hotplug ram), not containing bugfixes, not tested by QE.

If you're fine with that (e.g. testing a new setup not intended for production) then feel free to go ahead, but you could as well add it in 3.5 compatibility mode

(In reply to Michal Skrivanek from comment #11)
> (In reply to Marina from comment #9)
> > (In reply to Michal Skrivanek from comment #5)
> > > The released content doesn't correspond to what should be out there. Please
> > > check qemu-kvm-rhev version, it is likely an old 7.1-based one
> > 
> > Indeed, this is what I see on my machine:
> > ~~~
> > # rpm -q qemu-kvm-rhev
> > qemu-kvm-rhev-2.1.2-23.el7_1.10.x86_64
> > ~~~
> > 
> > However, I do not see why this should be a problem and why we just cannot
> > update the default list of emulated machines on the engine to include the
> > rhel7.1? (unless it is not a static list and actually generated on the fly,
> > I do not believe it is.)
> 
> Please don't do that. It will allow you to add the host all right, but you
> are running a _wrong_ QEMU, the one not supporting fully the 3.6 features
> (notably hotplug ram), not containing bugfixes, not tested by QE.
> 
> If you're fine with that (e.g. testing a new setup not intended for
> production) then feel free to go ahead, but you could as well add it in 3.5
> compatibility mode

Michal, ok. I am 100% with you on the compatibility and testing.
HOWEVER: if vdsm requires that specific package, why didn't it update it when installed?