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

Mon Jan 15 15:40:31 UTC 2018

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 at 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 at redhat.com> wrote:
> >
> >
> > On 12 Jan 2018, at 17:32, Yaniv Kaul <ykaul at redhat.com> wrote:
> >
> >
> >
> > On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek
> > <michal.skrivanek at redhat.com> wrote:
> >>
> >>
> >>
> >> On 12 Jan 2018, at 08:32, Tomas Jelinek <tjelinek at redhat.com> wrote:
> >>
> >>
> >>
> >> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <ykaul at redhat.com> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <ykaul at 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 at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>

-- 
*GAL bEN HAIM*
RHV DEVOPS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180115/cf5db00e/attachment-0001.html>