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

Gal Ben Haim gbenhaim at redhat.com
Mon Jan 15 17:21:31 UTC 2018


As a workaround, we can map *-IBRS: Intel * Family

On Mon, Jan 15, 2018 at 5:52 PM, Eyal Edri <eedri at redhat.com> wrote:

>
>
> On Mon, Jan 15, 2018 at 5:46 PM, Nadav Goldin <ngoldin at virtual-gate.net>
> wrote:
>
>> Maybe related to [1]?
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1533125
>
>
> 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]
>
>
>>
>>
>>
>> On Mon, Jan 15, 2018 at 5:40 PM, Gal Ben Haim <gbenhaim at 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 <
>> 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-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",
>> 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
>> _______________________________________________
>> Devel mailing list
>> Devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180115/f3e9c4aa/attachment.html>


More information about the Devel mailing list