Description of problem: RHEL 7 reports the CPU flag spec_ctrl that is part of all IBRS CPU type in ovirt-engine, but RHEL 8 does not report this flag. It rather utilises the bugs field in /proc/cpuinfo. Version-Release number of selected component (if applicable): ovirt-engine-4.4.0-0.33 How reproducible: 100% Steps to Reproduce: 1. Crate cluster with IBRS CPU 2. Upgrade hosted engine Actual results: Upgrade fails with the deploy host in non-operational state Expected results: Upgrade is successful Additional info: RHEL7: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid xsaveopt arat md_clear spec_ctrl RHEL8: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid xsaveopt arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
Sandro, are we even supporting in-place no redeploy HE?
It seems it indeed disappeared from cpu flags which is a problem for Name-IBRS specifically since that's the only one where we use "Name,+flag" instead. We can probably change that to Name-IBRS safely even for older Cluster Levels
(In reply to Ryan Barry from comment #1) > Sandro, are we even supporting in-place no redeploy HE? Not sure I understood the question. Hosted engine upgrade flow from 4.3 to 4.4 requires a host reinstall with 4.4 followed by re-deploy of hosted engine with restore of the engine from backup. Does this answer?
(In reply to Ryan Barry from comment #1) > Sandro, are we even supporting in-place no redeploy HE? Just to make it more clear. It is not an in-place upgrade. Everything is redeployed. The problem is the cluster CPU type which is set in the cluster in the DB which is restored. The new host is added to that cluster and has to comply with the CPU type set there. In my case, I used one with IBRS. The stage when the deployment waits for the host to become up fails as the host flips to the non-operational state due to the missing flag.
We still have vdsm-4.40.19-1.el8ev.x86_64.rpm 2020-06-04 available to QA.
I think that this bug is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1837266, because I used IBRS hosts too and the upgrade failed. As 1837266 was opened 2020-05-19, prior to this very bug, I think we should close it as a duplicate to 1837266.
I agree. What about you, Arik?
Right *** This bug has been marked as a duplicate of bug 1837266 ***