Description of problem: Host is reported as 'Error' status, with the following casting exception in engine.log: 2015-03-04 15:05:24,288 ERROR [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-54) Failure to refresh Vds green-vdsa runtime info. Incorrect vdsm version for cluster c1: java.l ang.ClassCastException: java.util.LinkedHashMap cannot be cast to java.lang.String at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder.buildVMDynamicDataFromList(VdsBrokerObjectsBuilder.java:97) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.ListVDSCommand.executeVdsBrokerCommand(ListVDSCommand.java:27) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:96) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:56) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:418) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.fetchRunningVms(VdsUpdateRunTimeInfo.java:991) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refreshVmStats(VdsUpdateRunTimeInfo.java:940) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refreshVdsRunTimeInfo(VdsUpdateRunTimeInfo.java:658) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refresh(VdsUpdateRunTimeInfo.java:494) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:236) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source) [:1.7.0_75] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_75] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75] at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:] at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:] at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:] Version-Release number of selected component (if applicable): Engine: rhev3.5.0-2 vt14 rhevm-3.5.1-0.1.el6ev.noarch Host: rhev3.5.0-2 rhel6.6 host vdsm-4.16.8.1-7.el6ev.x86_64 libvirt-0.10.2-46.el6_6.3.x86_64 How reproducible: Happens with vdsm installed on rhel6.6 Steps to Reproduce: 1. Add a rhel6.6 host to the setup Actual results: After host activation in DC, it enters to 'Error' status. The mentioned casting exception appears in engine.log Host cannot be activated. Expected results: Host should function. Additional info: This looks like a regression logs from host and engine are attached
Created attachment 997944 [details] logs from host
Created attachment 997946 [details] Screeshot from webadmin
Is this issue not related to BZ 1196327? It seems that you installed older engine and vdsm containing fix for above issue. Can you please update your engine and check whether the problem still occurs?
Checked with rhevm 3.5.0-0.33.el6ev (vt13.12), The issue doesn't occur.
(In reply to Elad from comment #5) > Checked with rhevm 3.5.0-0.33.el6ev (vt13.12), The issue doesn't occur. that does not make sense please doublecheck the version of vdsm and engine you are _running_ at that time (and that it's json-rpc)
The version I first checked and encountered the bug was rhevm-3.5.1-0.1.el6ev.noarch (vt14). Now I checked with 3.5.0-0.33.el6ev, vdsm-4.16.8.1-7.el7ev.x86_64 (vt13.12).
ok, so after veryfing git and the reported versions in log you are _not_ running 3.5.0-2 engine, but 3.5.1 build vt14, which does not contain the fix bug 1198248. This will be in the next 3.5.1 respin moving to MODIFY pending build and verification on 3.5.1
The issue occurs also with older engine build (checked with 3.5.0-1 - vt13.11). It doesn't seem to be related to a specific RHEL version.
keep in mind this bug doesn't have any tracker attached and wasn't found in any patch. it will remind in MODIFIED and for now doesn't seem it's in rhev 3.5.1. if you know otherwise, please attached the patch as tracker and update bug.
issues here were caused by partial incorrect/broken attempts to fix the getVMList issue it was re-targetted to 3.5.1 in the meantime so we can do all the verification there... *** This bug has been marked as a duplicate of bug 1198248 ***