As a workaround, we can map *-IBRS: Intel * Family On Mon, Jan 15, 2018 at 5:52 PM, Eyal Edri <eedri@redhat.com> wrote:
On Mon, Jan 15, 2018 at 5:46 PM, Nadav Goldin <ngoldin@virtual-gate.net> wrote:
Maybe related to [1]?
Seems like this is the cause.
This is for RHEL 7.5, if its related then we should look at the 7.4.z clone:
*Bug 1533418* <https://bugzilla.redhat.com/show_bug.cgi?id=1533418> - Libvirt may prefer $CPUModel over $CPUModel-IBRS when reporting host CPU model [rhel-7.4.z]
I've tried to run 'basic-suite-master' with [1], but I'm getting the following error:
_ID: VDS_CPU_LOWER_THAN_CLUSTER(515), Host lago-basic-suite-master-host-1 moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU features : model_Haswell-noTSX-IBRS
When running virsh on the host I see the following CPU:
<model>Haswell-noTSX-IBRS</model>
The CPU definition in the dom xml of the host:
<cpu mode='host-passthrough' check='none'> <topology sockets='2' cores='1' threads='1'/> </cpu>
When running virsh on the VM (ovirt host) I see the following CPU:
<model>Haswell-noTSX</model>
Which doesn't match the CPU of the host.
thoughts?
[1] https://github.com/lago-project/lago-ost-plugin/pull/31
On Sun, Jan 14, 2018 at 11:46 PM, Nadav Goldin < ngoldin@virtual-gate.net> wrote:
Trying to put together what I remember: 1. We had a QEMU bug where it was stated clearly that nested-virtualization is only supported when using 'host-passthrough' (don't know if that had changed since). 2. As consequence of (1) - Lago uses by default host-passthrough. 3. When running O-S-T, we needed a deterministic way to decide which cluster level to use, taking into account that VDMS's CPU, can be, theoretically, anything. 4. That is why you see 'Skylake' and 'IvyBridge' there - to match possible users of OST. 5. Lago already uses 'virsh capabilities' to report the L1 VM's CPU, lago-ost-plugin uses that report as the input key to the mapping file.
As far as I remember, we settled for this method after several on-going reports of users unable to run OST on their laptops due to CPU issues.
On Fri, Jan 12, 2018 at 6:49 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 12 Jan 2018, at 17:32, Yaniv Kaul <ykaul@redhat.com> wrote:
On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 12 Jan 2018, at 08:32, Tomas Jelinek <tjelinek@redhat.com>
wrote:
On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <ykaul@redhat.com>
wrote:
> > > > On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <ykaul@redhat.com> wrote: >> >> See[1] - do we need to update Lago / Lago OST plugin? > > > Something like https://github.com/lago-projec t/lago-ost-plugin/pull/31 > perhaps (not tested, don't have the HW).
yes, seems like that should do the trick.
sure, though, that list is also difficult to maintain e.g. IvyBridge is not an oVirt supported model, there’s no “Skylake” model
Nadav, what’s the exact purpose of that list, and can it be eliminated somehow?
It's to match, as possible, between the host CPU (which is passed to L1) so it'll match oVirt’s.
getting it from "virsh capabilities" on the host would match it a bit better. It would be enough to just make the L1 host report (via fake caps hook if needed) the same model_X in getVdsCapabilities as the L0
It's not that difficult to maintain. We add new CPUs once-twice a year…?
yes, not often
Y.
Thanks, michal
> > Y. > >> >> Error Message >> >> Unsupported CPU model: Haswell-noTSX-IBRS. Supported models: >> >> IvyBridge,Westmere,Skylake,Penryn,Haswell,Broadwell,Nehalem,
Skylake-Client,Broadwell-noTSX,Conroe,SandyBridge,Haswell-noTSX
>> >> Stacktrace >> >> Traceback (most recent call last): >> File "/usr/lib64/python2.7/unittest/case.py", line 369, in run >> testMethod() >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py",
>> 129, in wrapped_test >> test() >> File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py",
>> 59, >> in wrapper >> return func(get_test_prefix(), *args, **kwargs) >> File >> >> "/home/jenkins/workspace/ovirt-system-tests_master_check-
>> line 277, in add_cluster >> add_cluster_4(prefix) >> File >> >> "/home/jenkins/workspace/ovirt-system-tests_master_check-
On Mon, Jan 15, 2018 at 5:40 PM, Gal Ben Haim <gbenhaim@redhat.com> wrote: line line patch-el7-x86_64/ovirt-system-tests/basic-suite-master/test- scenarios/002_bootstrap.py", patch-el7-x86_64/ovirt-system-tests/basic-suite-master/test- scenarios/002_bootstrap.py",
>> line 305, in add_cluster_4 >> cpu_family = prefix.virt_env.get_ovirt_cpu_family() >> File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line >> 151, >> in get_ovirt_cpu_family >> ','.join(cpu_map[host.cpu_vendor].iterkeys()) >> RuntimeError: Unsupported CPU model: Haswell-noTSX-IBRS. Supported >> models: >> >> IvyBridge,Westmere,Skylake,Penryn,Haswell,Broadwell,Nehalem, Skylake-Client,Broadwell-noTSX,Conroe,SandyBridge,Haswell-noTSX >> >> >> >> Y. >> >> [1] >> >> http://jenkins.ovirt.org/job/ovirt-system-tests_master_check -patch-el7-x86_64/3498/testReport/junit/(root)/002_bootstrap/add_cluster/ > > > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- GAL bEN HAIM RHV DEVOPS
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--
Eyal edri
MANAGER
RHV DevOps
EMEA VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 <+972%209-769-2018> irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- *GAL bEN HAIM* RHV DEVOPS