On Mon, Jan 15, 2018 at 5:46 PM, Nadav Goldin <ngol...@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* <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 <gbenh...@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 <ngol...@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.skriva...@redhat.com> wrote: > >> > > >> > > >> > On 12 Jan 2018, at 17:32, Yaniv Kaul <yk...@redhat.com> wrote: > >> > > >> > > >> > > >> > On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek > >> > <michal.skriva...@redhat.com> wrote: > >> >> > >> >> > >> >> > >> >> On 12 Jan 2018, at 08:32, Tomas Jelinek <tjeli...@redhat.com> wrote: > >> >> > >> >> > >> >> > >> >> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <yk...@redhat.com> > wrote: > >> >>> > >> >>> > >> >>> > >> >>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <yk...@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 <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
