<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 15, 2018 at 5:46 PM, Nadav Goldin <span dir="ltr"><<a href="mailto:ngoldin@virtual-gate.net" target="_blank">ngoldin@virtual-gate.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe related to [1]?<br>
<br>
[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1533125" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1533125</a></blockquote><div><br></div><div>This is for RHEL 7.5, if its related then we should look at the 7.4.z clone:</div><div><br></div><div><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1533418" style="color:rgb(102,153,204);font-family:"DejaVu Sans","Liberation Sans",sans-serif;font-size:16.25px;font-weight:700"><b>Bug 1533418</b></a><span style="color:rgb(0,0,0);font-family:"DejaVu Sans","Liberation Sans",sans-serif;font-size:16.25px;font-weight:700;background-color:rgb(208,208,208)"> -</span><span id="gmail-summary_alias_container" style="color:rgb(0,0,0);font-family:"DejaVu Sans","Liberation Sans",sans-serif;font-size:16.25px;font-weight:700"> <span id="gmail-short_desc_nonedit_display">Libvirt may prefer $CPUModel over $CPUModel-IBRS when reporting host CPU model [rhel-7.4.z]</span></span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
On Mon, Jan 15, 2018 at 5:40 PM, Gal Ben Haim <<a href="mailto:gbenhaim@redhat.com">gbenhaim@redhat.com</a>> wrote:<br>
> I've tried to run 'basic-suite-master' with [1], but I'm getting the<br>
> following error:<br>
><br>
> _ID: VDS_CPU_LOWER_THAN_CLUSTER(<wbr>515), Host lago-basic-suite-master-host-1<br>
> moved to Non-Operational state as host does not meet the cluster's minimum<br>
> CPU level. Missing CPU features : model_Haswell-noTSX-IBRS<br>
><br>
> When running virsh on the host I see the following CPU:<br>
><br>
> <model>Haswell-noTSX-IBRS</<wbr>model><br>
><br>
> The CPU definition in the dom xml of the host:<br>
><br>
> <cpu mode='host-passthrough' check='none'><br>
> <topology sockets='2' cores='1' threads='1'/><br>
> </cpu><br>
><br>
><br>
> When running virsh on the VM (ovirt host) I see the following CPU:<br>
><br>
> <model>Haswell-noTSX</model><br>
><br>
> Which doesn't match the CPU of the host.<br>
><br>
> thoughts?<br>
><br>
><br>
> [1] <a href="https://github.com/lago-project/lago-ost-plugin/pull/31" rel="noreferrer" target="_blank">https://github.com/lago-<wbr>project/lago-ost-plugin/pull/<wbr>31</a><br>
><br>
> On Sun, Jan 14, 2018 at 11:46 PM, Nadav Goldin <<a href="mailto:ngoldin@virtual-gate.net">ngoldin@virtual-gate.net</a>><br>
> wrote:<br>
>><br>
>> Trying to put together what I remember:<br>
>> 1. We had a QEMU bug where it was stated clearly that<br>
>> nested-virtualization is only supported when using 'host-passthrough'<br>
>> (don't know if that had changed since).<br>
>> 2. As consequence of (1) - Lago uses by default host-passthrough.<br>
>> 3. When running O-S-T, we needed a deterministic way to decide which<br>
>> cluster level to use, taking into account that VDMS's CPU, can be,<br>
>> theoretically, anything.<br>
>> 4. That is why you see 'Skylake' and 'IvyBridge' there - to match<br>
>> possible users of OST.<br>
>> 5. Lago already uses 'virsh capabilities' to report the L1 VM's CPU,<br>
>> lago-ost-plugin uses that report as the input key to the mapping file.<br>
>><br>
>> As far as I remember, we settled for this method after several<br>
>> on-going reports of users unable to run OST on their laptops due to<br>
>> CPU issues.<br>
>><br>
>><br>
>><br>
>> On Fri, Jan 12, 2018 at 6:49 PM, Michal Skrivanek<br>
>> <<a href="mailto:michal.skrivanek@redhat.com">michal.skrivanek@redhat.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On 12 Jan 2018, at 17:32, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek<br>
>> > <<a href="mailto:michal.skrivanek@redhat.com">michal.skrivanek@redhat.com</a>> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On 12 Jan 2018, at 08:32, Tomas Jelinek <<a href="mailto:tjelinek@redhat.com">tjelinek@redhat.com</a>> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
>> >>>><br>
>> >>>> See[1] - do we need to update Lago / Lago OST plugin?<br>
>> >>><br>
>> >>><br>
>> >>> Something like <a href="https://github.com/lago-project/lago-ost-plugin/pull/31" rel="noreferrer" target="_blank">https://github.com/lago-<wbr>project/lago-ost-plugin/pull/<wbr>31</a><br>
>> >>> perhaps (not tested, don't have the HW).<br>
>> >><br>
>> >><br>
>> >> yes, seems like that should do the trick.<br>
>> >><br>
>> >><br>
>> >> sure, though, that list is also difficult to maintain<br>
>> >> e.g. IvyBridge is not an oVirt supported model, there’s no “Skylake”<br>
>> >> model<br>
>> >><br>
>> >> Nadav, what’s the exact purpose of that list, and can it be eliminated<br>
>> >> somehow?<br>
>> ><br>
>> ><br>
>> > It's to match, as possible, between the host CPU (which is passed to L1)<br>
>> > so<br>
>> > it'll match oVirt’s.<br>
>> ><br>
>> ><br>
>> > getting it from "virsh capabilities" on the host would match it a bit<br>
>> > better. It would be enough to just make the L1 host report (via fake<br>
>> > caps<br>
>> > hook if needed) the same model_X in getVdsCapabilities as the L0<br>
>> ><br>
>> > It's not that difficult to maintain. We add new CPUs once-twice a year…?<br>
>> ><br>
>> ><br>
>> > yes, not often<br>
>> ><br>
>> > Y.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> Thanks,<br>
>> >> michal<br>
>> >><br>
>> >><br>
>> >><br>
>> >>><br>
>> >>> Y.<br>
>> >>><br>
>> >>>><br>
>> >>>> Error Message<br>
>> >>>><br>
>> >>>> Unsupported CPU model: Haswell-noTSX-IBRS. Supported models:<br>
>> >>>><br>
>> >>>> IvyBridge,Westmere,Skylake,<wbr>Penryn,Haswell,Broadwell,<wbr>Nehalem,Skylake-Client,<wbr>Broadwell-noTSX,Conroe,<wbr>SandyBridge,Haswell-noTSX<br>
>> >>>><br>
>> >>>> Stacktrace<br>
>> >>>><br>
>> >>>> Traceback (most recent call last):<br>
>> >>>> File "/usr/lib64/python2.7/<wbr>unittest/case.py", line 369, in run<br>
>> >>>> testMethod()<br>
>> >>>> File "/usr/lib/python2.7/site-<wbr>packages/nose/case.py", line 197, in<br>
>> >>>> runTest<br>
>> >>>> self.test(*self.arg)<br>
>> >>>> File "/usr/lib/python2.7/site-<wbr>packages/ovirtlago/testlib.py"<wbr>, line<br>
>> >>>> 129, in wrapped_test<br>
>> >>>> test()<br>
>> >>>> File "/usr/lib/python2.7/site-<wbr>packages/ovirtlago/testlib.py"<wbr>, line<br>
>> >>>> 59,<br>
>> >>>> in wrapper<br>
>> >>>> return func(get_test_prefix(), *args, **kwargs)<br>
>> >>>> File<br>
>> >>>><br>
>> >>>> "/home/jenkins/workspace/<wbr>ovirt-system-tests_master_<wbr>check-patch-el7-x86_64/ovirt-<wbr>system-tests/basic-suite-<wbr>master/test-scenarios/002_<wbr>bootstrap.py",<br>
>> >>>> line 277, in add_cluster<br>
>> >>>> add_cluster_4(prefix)<br>
>> >>>> File<br>
>> >>>><br>
>> >>>> "/home/jenkins/workspace/<wbr>ovirt-system-tests_master_<wbr>check-patch-el7-x86_64/ovirt-<wbr>system-tests/basic-suite-<wbr>master/test-scenarios/002_<wbr>bootstrap.py",<br>
>> >>>> line 305, in add_cluster_4<br>
>> >>>> cpu_family = prefix.virt_env.get_ovirt_cpu_<wbr>family()<br>
>> >>>> File "/usr/lib/python2.7/site-<wbr>packages/ovirtlago/virt.py", line<br>
>> >>>> 151,<br>
>> >>>> in get_ovirt_cpu_family<br>
>> >>>> ','.join(cpu_map[host.cpu_<wbr>vendor].iterkeys())<br>
>> >>>> RuntimeError: Unsupported CPU model: Haswell-noTSX-IBRS. Supported<br>
>> >>>> models:<br>
>> >>>><br>
>> >>>> IvyBridge,Westmere,Skylake,<wbr>Penryn,Haswell,Broadwell,<wbr>Nehalem,Skylake-Client,<wbr>Broadwell-noTSX,Conroe,<wbr>SandyBridge,Haswell-noTSX<br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> Y.<br>
>> >>>><br>
>> >>>> [1]<br>
>> >>>><br>
>> >>>> <a href="http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x86_64/3498/testReport/junit/(root)/002_bootstrap/add_cluster/" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ovirt-system-tests_master_<wbr>check-patch-el7-x86_64/3498/<wbr>testReport/junit/(root)/002_<wbr>bootstrap/add_cluster/</a><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> ______________________________<wbr>_________________<br>
>> >>> Devel mailing list<br>
>> >>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> >><br>
>> >><br>
>> >> ______________________________<wbr>_________________<br>
>> >> Devel mailing list<br>
>> >> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Devel mailing list<br>
>> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> ______________________________<wbr>_________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
><br>
><br>
> --<br>
> GAL bEN HAIM<br>
> RHV DEVOPS<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><p style="font-family:overpass,sans-serif;margin:0px;padding:0px;font-size:14px;text-transform:uppercase;font-weight:bold"><font color="#cc0000">Eyal edri</font></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><br></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase">MANAGER</p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase">RHV DevOps</p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase">EMEA VIRTUALIZATION R&D</p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><br></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat EMEA</a></p><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" style="color:rgb(17,85,204)" target="_blank"><img src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png" width="90" height="auto"></a></td><td style="font-size:10px"><a href="https://redhat.com/trusted" style="color:rgb(204,0,0);font-weight:bold" target="_blank">TRIED. TESTED. TRUSTED.</a></td></tr></tbody></table></div><div>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div></div></div></div></div></div></div>
</div></div>