Re: [ovirt-devel] OST Regression in add cluster (IBRS related)

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(a)virtual-gate.net&gt; 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(a)redhat.com&gt; wrote: > > > > > > On 12 Jan 2018, at 17:32, Yaniv Kaul <ykaul(a)redhat.com&gt; wrote: > > > > > > > > On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek > > <michal.skrivanek(a)redhat.com&gt; wrote: > >> > >> > >> > >> On 12 Jan 2018, at 08:32, Tomas Jelinek <tjelinek(a)redhat.com&gt; wrote: > >> > >> > >> > >> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <ykaul(a)redhat.com&gt; wrote: > >>> > >>> > >>> > >>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <ykaul(a)redhat.com&gt; 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-x8... > >>> > >>> > >>> > >>> _______________________________________________ > >>> Devel mailing list > >>> Devel(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/devel > >> > >> > >> _______________________________________________ > >> Devel mailing list > >> Devel(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel -- GAL bEN HAIM RHV DEVOPS