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