On Mon, Jan 15, 2018 at 5:46 PM, Nadav Goldin <ngoldin@virtual-gate.net> wrote:

Maybe related to [1]?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1533125

This is for RHEL 7.5, if its related then we should look at the 7.4.z clone:

Bug 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@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@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-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

--

Eyal edri

MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D

Red Hat EMEA

TRIED. TESTED. TRUSTED.

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)