Maybe related to [1]? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1533125
On Mon, Jan 15, 2018 at 5:40 PM, Gal Ben Haim <gbenh...@redhat.com> wrote: > 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 <ngol...@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.skriva...@redhat.com> wrote: >> > >> > >> > On 12 Jan 2018, at 17:32, Yaniv Kaul <yk...@redhat.com> wrote: >> > >> > >> > >> > On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek >> > <michal.skriva...@redhat.com> wrote: >> >> >> >> >> >> >> >> On 12 Jan 2018, at 08:32, Tomas Jelinek <tjeli...@redhat.com> wrote: >> >> >> >> >> >> >> >> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <yk...@redhat.com> wrote: >> >>> >> >>> >> >>> >> >>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <yk...@redhat.com> wrote: >> >>>> >> >>>> See[1] - do we need to update Lago / Lago OST plugin? >> >>> >> >>> >> >>> Something like https://github.com/lago-project/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", line >> >>>> 129, in wrapped_test >> >>>> test() >> >>>> File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line >> >>>> 59, >> >>>> in wrapper >> >>>> return func(get_test_prefix(), *args, **kwargs) >> >>>> File >> >>>> >> >>>> "/home/jenkins/workspace/ovirt-system-tests_master_check-patch-el7-x86_64/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", >> >>>> line 277, in add_cluster >> >>>> add_cluster_4(prefix) >> >>>> File >> >>>> >> >>>> "/home/jenkins/workspace/ovirt-system-tests_master_check-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