What is the host CPU you are using? I came across the same error few days ago, but without running OST, I tried running with Lago: fc24 host -> el7 vm -> el7 vm. I have a slight suspect that it is related to the CPU model we configure in libvirt, I tried a mixture of few combinations(host-pass-through, pinning down the CPU model), but it always failed on the same error: kvm_put_msrs: Assertion `ret == n' failed. My CPU is Broadwell btw. Milan, any ideas? you think it might be related? Nadav. On Tue, Feb 7, 2017 at 11:14 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; wrote: > Yes, I stated that in my message. > > root@osvoboda-t460p /home/src/ovirt-system-tests (git)-[master] # cat > /sys/module/kvm_intel/parameters/nested > :( > Y > > On Tue, Feb 7, 2017 at 1:39 PM, Eyal Edri <eedri(a)redhat.com&gt; wrote: >> >> Did you follow the instructions on [1] ? >> >> Specifically, verifying ' cat /sys/module/kvm_intel/parameters/nested ' >> gives you 'Y'. >> >> [1] >> http://ovirt-system-tests.readthedocs.io/en/latest/docs/ general/installation.html >> >> On Tue, Feb 7, 2017 at 2:29 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; >> wrote: >>> >>> Hi everyone, >>> >>> Even though I have nested virtualization enabled in my Arch Linux system >>> which I use to run OST, vm_run is the first test to fail in 004_basic_sanity >>> (followed by snapshots_merge and suspend_resume_vm). >>> >>> Can you point me to what I might be missing? I believe I get the same >>> failure even on Fedora. >>> >>> This is what host0's CPU capabilities look like (vmx is there): >>> [root@lago-basic-suite-master-host0 ~]# cat /proc/cpuinfo >>> processor : 0 >>> vendor_id : GenuineIntel >>> cpu family : 6 >>> model : 44 >>> model name : Westmere E56xx/L56xx/X56xx (Nehalem-C) >>> stepping : 1 >>> microcode : 0x1 >>> cpu MHz : 2711.988 >>> cache size : 16384 KB >>> physical id : 0 >>> siblings : 1 >>> core id : 0 >>> cpu cores : 1 >>> apicid : 0 >>> initial apicid : 0 >>> fpu : yes >>> fpu_exception : yes >>> cpuid level : 11 >>> wp : yes >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca >>> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good >>> nopl xtopology pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes >>> hypervisor lahf_lm arat tpr_shadow vnmi flexpriority ept vpid >>> bogomips : 5423.97 >>> clflush size : 64 >>> cache_alignment : 64 >>> address sizes : 40 bits physical, 48 bits virtual >>> power management: >>> >>> journalctl -b on host0 shows that libvirt complains about NUMA >>> configuration: >>> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: libvirt >>> version: 2.0.0, package: 10.el7_3.4 (CentOS BuildSystem >>> <http://bugs.centos.org>;, 2017-01-17-23:37:48, c1bm.rdu2.centos.org) >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: port >>> 2(vnet0) entered disabled state >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: device vnet0 left >>> promiscuous mode >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: port >>> 2(vnet0) entered disabled state >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: hostname: >>> lago-basic-suite-master-host0.lago.local >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: Unable to >>> read from monitor: Connection reset by peer >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: internal >>> error: qemu unexpectedly closed the monitor: 2017-02-07T11:33:23.058571Z >>> qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 6 7 8 9 >>> 10 11 12 13 14 15 >>> >>> 2017-02-07T11:33:23.058826Z qemu-kvm: warning: All CPU(s) up to maxcpus >>> should be described in NUMA config >>> qemu-kvm: >>> /builddir/build/BUILD/qemu-2.6.0/target-i386/kvm.c:1736: kvm_put_msrs: >>> Assertion `ret == n' failed. >>> Feb 07 06:33:23 lago-basic-suite-master-host0 NetworkManager[657]: <info> >>> [1486467203.1025] device (vnet0): state change: disconnected -> unmanaged >>> (reason 'unmanaged') [30 10 3] >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kvm[22059]: 0 guests now >>> active >>> Feb 07 06:33:23 lago-basic-suite-master-host0 systemd-machined[22044]: >>> Machine qemu-1-vm0 terminated. >>> >>> Thanks, >>> Ondra >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >> >> >> >> >> -- >> Eyal Edri >> Associate Manager >> RHV DevOps >> EMEA ENG Virtualization R&D >> Red Hat Israel >> >> phone: +972-9-7692018 >> irc: eedri (on #tlv #rhev-dev #rhev-integ) > > > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel

I would first try testing it without OST, because in OST it will pick the CPU via the cluster family(which is controlled in virt.py). You can try specifying the 'cpu_model' in the init file, skipping the 'cpu family' logic, something like: > cat LagoInitFile domains: vm-el73: memory: 2048 service_provider: systemd cpu_model: Broadwell nics: - net: lago disks: - template_name: el7.3-base type: template name: root dev: vda format: qcow2 nets: lago: type: nat dhcp: start: 100 end: 254 management: true dns_domain_name: lago.local > lago init && lago start Then install lago again in the VM, copy the same init file, and check if for different combinations of cpu_model it works for you - would give us a hint how to solve this. The 'cpu_model' basically translates to this xml definition in libvirt: <cpu mode='custom' match='exact'> <model fallback='allow'>Broadwell</model> <topology sockets='2' cores='1' threads='1'/> <feature policy='optional' name='vmx'/> <feature policy='optional' name='svm'/> </cpu> I tried manually editing it also to host-passthrough, but still failed on the same error. The thing is that the 'kvm_put_msrs: Assertion `ret == n' failed.' error doesn't give any indication where it failed(or if the cpu is missing a flag), maybe there is a way to debug this at qemu/kvm level? I'm not sure. On Wed, Feb 8, 2017 at 1:18 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; wrote: > It is a Skylake-H, and I can see it is not mentioned in lago/virt.py. > > I guess I'll step through the code (as well as other places discovered by > 'git grep cpu') and see if I could solve this by adding the Skylake family > to _CPU_FAMILIES. > > Do you have other pointers? > > Thanks, > Ondra > > On Tue, Feb 7, 2017 at 10:40 PM, Nadav Goldin <ngoldin(a)redhat.com&gt; wrote: >> >> What is the host CPU you are using? >> I came across the same error few days ago, but without running OST, I >> tried running with Lago: >> fc24 host -> el7 vm -> el7 vm. >> >> I have a slight suspect that it is related to the CPU model we >> configure in libvirt, I tried a mixture of few >> combinations(host-pass-through, pinning down the CPU model), but it >> always failed on the same error: >> kvm_put_msrs: Assertion `ret == n' failed. >> >> My CPU is Broadwell btw. >> >> >> Milan, any ideas? you think it might be related? >> >> Nadav. >> >> >> >> On Tue, Feb 7, 2017 at 11:14 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; >> wrote: >> > Yes, I stated that in my message. >> > >> > root@osvoboda-t460p /home/src/ovirt-system-tests (git)-[master] # cat >> > /sys/module/kvm_intel/parameters/nested >> > :( >> > Y >> > >> > On Tue, Feb 7, 2017 at 1:39 PM, Eyal Edri <eedri(a)redhat.com&gt; wrote: >> >> >> >> Did you follow the instructions on [1] ? >> >> >> >> Specifically, verifying ' cat /sys/module/kvm_intel/ parameters/nested >> >> ' >> >> gives you 'Y'. >> >> >> >> [1] >> >> >> >> http://ovirt-system-tests.readthedocs.io/en/latest/docs/ general/installation.html >> >> >> >> On Tue, Feb 7, 2017 at 2:29 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; >> >> wrote: >> >>> >> >>> Hi everyone, >> >>> >> >>> Even though I have nested virtualization enabled in my Arch Linux >> >>> system >> >>> which I use to run OST, vm_run is the first test to fail in >> >>> 004_basic_sanity >> >>> (followed by snapshots_merge and suspend_resume_vm). >> >>> >> >>> Can you point me to what I might be missing? I believe I get the same >> >>> failure even on Fedora. >> >>> >> >>> This is what host0's CPU capabilities look like (vmx is there): >> >>> [root@lago-basic-suite-master-host0 ~]# cat /proc/cpuinfo >> >>> processor : 0 >> >>> vendor_id : GenuineIntel >> >>> cpu family : 6 >> >>> model : 44 >> >>> model name : Westmere E56xx/L56xx/X56xx (Nehalem-C) >> >>> stepping : 1 >> >>> microcode : 0x1 >> >>> cpu MHz : 2711.988 >> >>> cache size : 16384 KB >> >>> physical id : 0 >> >>> siblings : 1 >> >>> core id : 0 >> >>> cpu cores : 1 >> >>> apicid : 0 >> >>> initial apicid : 0 >> >>> fpu : yes >> >>> fpu_exception : yes >> >>> cpuid level : 11 >> >>> wp : yes >> >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >> >>> mca >> >>> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc >> >>> rep_good >> >>> nopl xtopology pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic >> >>> popcnt aes >> >>> hypervisor lahf_lm arat tpr_shadow vnmi flexpriority ept vpid >> >>> bogomips : 5423.97 >> >>> clflush size : 64 >> >>> cache_alignment : 64 >> >>> address sizes : 40 bits physical, 48 bits virtual >> >>> power management: >> >>> >> >>> journalctl -b on host0 shows that libvirt complains about NUMA >> >>> configuration: >> >>> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: libvirt >> >>> version: 2.0.0, package: 10.el7_3.4 (CentOS BuildSystem >> >>> <http://bugs.centos.org>;, 2017-01-17-23:37:48, c1bm.rdu2.centos.org ) >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: port >> >>> 2(vnet0) entered disabled state >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: device vnet0 >> >>> left >> >>> promiscuous mode >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: port >> >>> 2(vnet0) entered disabled state >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: >> >>> hostname: >> >>> lago-basic-suite-master-host0.lago.local >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: Unable >> >>> to >> >>> read from monitor: Connection reset by peer >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: >> >>> internal >> >>> error: qemu unexpectedly closed the monitor: >> >>> 2017-02-07T11:33:23.058571Z >> >>> qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 6 7 >> >>> 8 9 >> >>> 10 11 12 13 14 15 >> >>> >> >>> 2017-02-07T11:33:23.058826Z qemu-kvm: warning: All CPU(s) up to >> >>> maxcpus >> >>> should be described in NUMA config >> >>> >> >>> qemu-kvm: >> >>> /builddir/build/BUILD/qemu-2.6.0/target-i386/kvm.c:1736: kvm_put_msrs: >> >>> Assertion `ret == n' failed. >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 NetworkManager[657]: >> >>> <info> >> >>> [1486467203.1025] device (vnet0): state change: disconnected -> >> >>> unmanaged >> >>> (reason 'unmanaged') [30 10 3] >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kvm[22059]: 0 guests now >> >>> active >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 systemd-machined[22044]: >> >>> Machine qemu-1-vm0 terminated. >> >>> >> >>> Thanks, >> >>> Ondra >> >>> >> >>> _______________________________________________ >> >>> Devel mailing list >> >>> Devel(a)ovirt.org >> >>> http://lists.ovirt.org/mailman/listinfo/devel >> >> >> >> >> >> >> >> >> >> -- >> >> Eyal Edri >> >> Associate Manager >> >> RHV DevOps >> >> EMEA ENG Virtualization R&D >> >> Red Hat Israel >> >> >> >> phone: +972-9-7692018 >> >> irc: eedri (on #tlv #rhev-dev #rhev-integ) >> > >> > >> > >> > _______________________________________________ >> > Devel mailing list >> > Devel(a)ovirt.org >> > http://lists.ovirt.org/mailman/listinfo/devel > >

What happened to Milan' PR from a while ago addressing this exact situation? On 08 Feb 2017, at 16:04, Ondrej Svoboda <osvoboda(a)redhat.com&gt; wrote: In my case, simply adding Skylake-Client a supported CPU family did the trick: https://github.com/lago-project/lago/pull/448 i wonder if Westmere is a good fallback -- it works for you on Broadwell, right? On Wed, Feb 8, 2017 at 1:58 PM, Nadav Goldin <ngoldin(a)redhat.com&gt; wrote: > I would first try testing it without OST, because in OST it will pick > the CPU via the cluster family(which is controlled in virt.py). You > can try specifying the 'cpu_model' in the init file, skipping the 'cpu > family' logic, something like: > > > cat LagoInitFile > domains: > vm-el73: > memory: 2048 > service_provider: systemd > cpu_model: Broadwell > nics: > - net: lago > disks: > - template_name: el7.3-base > type: template > name: root > dev: vda > format: qcow2 > nets: > lago: > type: nat > dhcp: > start: 100 > end: 254 > management: true > dns_domain_name: lago.local > > > lago init && lago start > > Then install lago again in the VM, copy the same init file, and check > if for different combinations of cpu_model it works for you - would > give us a hint how to solve this. The 'cpu_model' basically translates > to this xml definition in libvirt: > <cpu mode='custom' match='exact'> > <model fallback='allow'>Broadwell</model> > <topology sockets='2' cores='1' threads='1'/> > <feature policy='optional' name='vmx'/> > <feature policy='optional' name='svm'/> > </cpu> > > I tried manually editing it also to host-passthrough, but still failed > on the same error. The thing is that the 'kvm_put_msrs: Assertion `ret > == n' failed.' error doesn't give any indication where it failed(or if > the cpu is missing a flag), maybe there is a way to debug this at > qemu/kvm level? I'm not sure. > > > > > > > On Wed, Feb 8, 2017 at 1:18 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; > wrote: > > It is a Skylake-H, and I can see it is not mentioned in lago/virt.py. > > > > I guess I'll step through the code (as well as other places discovered > by > > 'git grep cpu') and see if I could solve this by adding the Skylake > family > > to _CPU_FAMILIES. > > > > Do you have other pointers? > > > > Thanks, > > Ondra > > > > On Tue, Feb 7, 2017 at 10:40 PM, Nadav Goldin <ngoldin(a)redhat.com&gt; > wrote: > >> > >> What is the host CPU you are using? > >> I came across the same error few days ago, but without running OST, I > >> tried running with Lago: > >> fc24 host -> el7 vm -> el7 vm. > >> > >> I have a slight suspect that it is related to the CPU model we > >> configure in libvirt, I tried a mixture of few > >> combinations(host-pass-through, pinning down the CPU model), but it > >> always failed on the same error: > >> kvm_put_msrs: Assertion `ret == n' failed. > >> > >> My CPU is Broadwell btw. > >> > >> > >> Milan, any ideas? you think it might be related? > >> > >> Nadav. > >> > >> > >> > >> On Tue, Feb 7, 2017 at 11:14 PM, Ondrej Svoboda <osvoboda(a)redhat.com&gt; > >> wrote: > >> > Yes, I stated that in my message. > >> > > >> > root@osvoboda-t460p /home/src/ovirt-system-tests (git)-[master] # > cat > >> > /sys/module/kvm_intel/parameters/nested > >> > :( > >> > Y > >> > > >> > On Tue, Feb 7, 2017 at 1:39 PM, Eyal Edri <eedri(a)redhat.com&gt; wrote: > >> >> > >> >> Did you follow the instructions on [1] ? > >> >> > >> >> Specifically, verifying ' cat /sys/module/kvm_intel/paramete > rs/nested > >> >> ' > >> >> gives you 'Y'. > >> >> > >> >> [1] > >> >> > >> >> http://ovirt-system-tests.readthedocs.io/en/latest/docs/gene > ral/installation.html > >> >> > >> >> On Tue, Feb 7, 2017 at 2:29 PM, Ondrej Svoboda <osvoboda(a)redhat.com > > > >> >> wrote: > >> >>> > >> >>> Hi everyone, > >> >>> > >> >>> Even though I have nested virtualization enabled in my Arch Linux > >> >>> system > >> >>> which I use to run OST, vm_run is the first test to fail in > >> >>> 004_basic_sanity > >> >>> (followed by snapshots_merge and suspend_resume_vm). > >> >>> > >> >>> Can you point me to what I might be missing? I believe I get the > same > >> >>> failure even on Fedora. > >> >>> > >> >>> This is what host0's CPU capabilities look like (vmx is there): > >> >>> [root@lago-basic-suite-master-host0 ~]# cat /proc/cpuinfo > >> >>> processor : 0 > >> >>> vendor_id : GenuineIntel > >> >>> cpu family : 6 > >> >>> model : 44 > >> >>> model name : Westmere E56xx/L56xx/X56xx (Nehalem-C) > >> >>> stepping : 1 > >> >>> microcode : 0x1 > >> >>> cpu MHz : 2711.988 > >> >>> cache size : 16384 KB > >> >>> physical id : 0 > >> >>> siblings : 1 > >> >>> core id : 0 > >> >>> cpu cores : 1 > >> >>> apicid : 0 > >> >>> initial apicid : 0 > >> >>> fpu : yes > >> >>> fpu_exception : yes > >> >>> cpuid level : 11 > >> >>> wp : yes > >> >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > >> >>> mca > >> >>> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc > >> >>> rep_good > >> >>> nopl xtopology pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic > >> >>> popcnt aes > >> >>> hypervisor lahf_lm arat tpr_shadow vnmi flexpriority ept vpid > >> >>> bogomips : 5423.97 > >> >>> clflush size : 64 > >> >>> cache_alignment : 64 > >> >>> address sizes : 40 bits physical, 48 bits virtual > >> >>> power management: > >> >>> > >> >>> journalctl -b on host0 shows that libvirt complains about NUMA > >> >>> configuration: > >> >>> > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: > libvirt > >> >>> version: 2.0.0, package: 10.el7_3.4 (CentOS BuildSystem > >> >>> <http://bugs.centos.org>;, 2017-01-17-23:37:48, > c1bm.rdu2.centos.org) > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: > port > >> >>> 2(vnet0) entered disabled state > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: device vnet0 > >> >>> left > >> >>> promiscuous mode > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: > port > >> >>> 2(vnet0) entered disabled state > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: > >> >>> hostname: > >> >>> lago-basic-suite-master-host0.lago.local > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: > Unable > >> >>> to > >> >>> read from monitor: Connection reset by peer > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: > >> >>> internal > >> >>> error: qemu unexpectedly closed the monitor: > >> >>> 2017-02-07T11:33:23.058571Z > >> >>> qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 > 6 7 > >> >>> 8 9 > >> >>> 10 11 12 13 14 15 > >> >>> > >> >>> 2017-02-07T11:33:23.058826Z qemu-kvm: warning: All CPU(s) up to > >> >>> maxcpus > >> >>> should be described in NUMA config > >> >>> > >> >>> qemu-kvm: > >> >>> /builddir/build/BUILD/qemu-2.6.0/target-i386/kvm.c:1736: > kvm_put_msrs: > >> >>> Assertion `ret == n' failed. > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 NetworkManager[657]: > >> >>> <info> > >> >>> [1486467203.1025] device (vnet0): state change: disconnected -> > >> >>> unmanaged > >> >>> (reason 'unmanaged') [30 10 3] > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kvm[22059]: 0 guests > now > >> >>> active > >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 > systemd-machined[22044]: > >> >>> Machine qemu-1-vm0 terminated. > >> >>> > >> >>> Thanks, > >> >>> Ondra > >> >>> > >> >>> _______________________________________________ > >> >>> Devel mailing list > >> >>> Devel(a)ovirt.org > >> >>> http://lists.ovirt.org/mailman/listinfo/devel > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Eyal Edri > >> >> Associate Manager > >> >> RHV DevOps > >> >> EMEA ENG Virtualization R&D > >> >> Red Hat Israel > >> >> > >> >> phone: +972-9-7692018 > >> >> irc: eedri (on #tlv #rhev-dev #rhev-integ) > >> > > >> > > >> > > >> > _______________________________________________ > >> > Devel mailing list > >> > Devel(a)ovirt.org > >> > http://lists.ovirt.org/mailman/listinfo/devel > > > > > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

On 10 Feb 2017, at 10:26, Michal Skrivanek <mskrivan(a)redhat.com&gt; wrote: > On 9 Feb 2017, at 16:16, Ondrej Svoboda <osvoboda(a)redhat.com <mailto:osvoboda@redhat.com>> wrote: > > Do you mean https://github.com/lago-project/lago/pull/398 <https://github.com/lago-project/lago/pull/398> which has been merged for over a month? > > The second sentence in the PR (below) is contradicted by newer, non-recognized CPUs, such as Skylake. How/why? Westmere should have been selected in that case

> > "This patch fixes the problems by selecting a minimum reasonable CPU model for the given hardware platform. Westmere is selected unless older or non-Intel hardware is used." > > On Thu, Feb 9, 2017 at 4:07 PM, Michal Skrivanek <mskrivan(a)redhat.com <mailto:mskrivan@redhat.com>> wrote: > What happened to Milan' PR from a while ago addressing this exact situation? > > On 08 Feb 2017, at 16:04, Ondrej Svoboda <osvoboda(a)redhat.com <mailto:osvoboda@redhat.com>> wrote: > >> In my case, simply adding Skylake-Client a supported CPU family did the trick: https://github.com/lago-project/lago/pull/448 <https://github.com/lago-project/lago/pull/448> >> >> i wonder if Westmere is a good fallback -- it works for you on Broadwell, right? >> >> On Wed, Feb 8, 2017 at 1:58 PM, Nadav Goldin <ngoldin(a)redhat.com <mailto:ngoldin@redhat.com>> wrote: >> I would first try testing it without OST, because in OST it will pick >> the CPU via the cluster family(which is controlled in virt.py). You >> can try specifying the 'cpu_model' in the init file, skipping the 'cpu >> family' logic, something like: >> >> > cat LagoInitFile >> domains: >> vm-el73: >> memory: 2048 >> service_provider: systemd >> cpu_model: Broadwell >> nics: >> - net: lago >> disks: >> - template_name: el7.3-base >> type: template >> name: root >> dev: vda >> format: qcow2 >> nets: >> lago: >> type: nat >> dhcp: >> start: 100 >> end: 254 >> management: true >> dns_domain_name: lago.local >> >> > lago init && lago start >> >> Then install lago again in the VM, copy the same init file, and check >> if for different combinations of cpu_model it works for you - would >> give us a hint how to solve this. The 'cpu_model' basically translates >> to this xml definition in libvirt: >> <cpu mode='custom' match='exact'> >> <model fallback='allow'>Broadwell</model> >> <topology sockets='2' cores='1' threads='1'/> >> <feature policy='optional' name='vmx'/> >> <feature policy='optional' name='svm'/> >> </cpu> >> >> I tried manually editing it also to host-passthrough, but still failed >> on the same error. The thing is that the 'kvm_put_msrs: Assertion `ret >> == n' failed.' error doesn't give any indication where it failed(or if >> the cpu is missing a flag), maybe there is a way to debug this at >> qemu/kvm level? I'm not sure. >> >> >> >> >> >> >> On Wed, Feb 8, 2017 at 1:18 PM, Ondrej Svoboda <osvoboda(a)redhat.com <mailto:osvoboda@redhat.com>> wrote: >> > It is a Skylake-H, and I can see it is not mentioned in lago/virt.py. >> > >> > I guess I'll step through the code (as well as other places discovered by >> > 'git grep cpu') and see if I could solve this by adding the Skylake family >> > to _CPU_FAMILIES. >> > >> > Do you have other pointers? >> > >> > Thanks, >> > Ondra >> > >> > On Tue, Feb 7, 2017 at 10:40 PM, Nadav Goldin <ngoldin(a)redhat.com <mailto:ngoldin@redhat.com>> wrote: >> >> >> >> What is the host CPU you are using? >> >> I came across the same error few days ago, but without running OST, I >> >> tried running with Lago: >> >> fc24 host -> el7 vm -> el7 vm. >> >> >> >> I have a slight suspect that it is related to the CPU model we >> >> configure in libvirt, I tried a mixture of few >> >> combinations(host-pass-through, pinning down the CPU model), but it >> >> always failed on the same error: >> >> kvm_put_msrs: Assertion `ret == n' failed. >> >> >> >> My CPU is Broadwell btw. >> >> >> >> >> >> Milan, any ideas? you think it might be related? >> >> >> >> Nadav. >> >> >> >> >> >> >> >> On Tue, Feb 7, 2017 at 11:14 PM, Ondrej Svoboda <osvoboda(a)redhat.com <mailto:osvoboda@redhat.com>> >> >> wrote: >> >> > Yes, I stated that in my message. >> >> > >> >> > root@osvoboda-t460p /home/src/ovirt-system-tests (git)-[master] # cat >> >> > /sys/module/kvm_intel/parameters/nested >> >> > :( >> >> > Y >> >> > >> >> > On Tue, Feb 7, 2017 at 1:39 PM, Eyal Edri <eedri(a)redhat.com <mailto:eedri@redhat.com>> wrote: >> >> >> >> >> >> Did you follow the instructions on [1] ? >> >> >> >> >> >> Specifically, verifying ' cat /sys/module/kvm_intel/parameters/nested >> >> >> ' >> >> >> gives you 'Y'. >> >> >> >> >> >> [1] >> >> >> >> >> >> http://ovirt-system-tests.readthedocs.io/en/latest/docs/general/installat... <http://ovirt-system-tests.readthedocs.io/en/latest/docs/general/installat... >> >> >> >> >> >> On Tue, Feb 7, 2017 at 2:29 PM, Ondrej Svoboda <osvoboda(a)redhat.com <mailto:osvoboda@redhat.com>> >> >> >> wrote: >> >> >>> >> >> >>> Hi everyone, >> >> >>> >> >> >>> Even though I have nested virtualization enabled in my Arch Linux >> >> >>> system >> >> >>> which I use to run OST, vm_run is the first test to fail in >> >> >>> 004_basic_sanity >> >> >>> (followed by snapshots_merge and suspend_resume_vm). >> >> >>> >> >> >>> Can you point me to what I might be missing? I believe I get the same >> >> >>> failure even on Fedora. >> >> >>> >> >> >>> This is what host0's CPU capabilities look like (vmx is there): >> >> >>> [root@lago-basic-suite-master-host0 ~]# cat /proc/cpuinfo >> >> >>> processor : 0 >> >> >>> vendor_id : GenuineIntel >> >> >>> cpu family : 6 >> >> >>> model : 44 >> >> >>> model name : Westmere E56xx/L56xx/X56xx (Nehalem-C) >> >> >>> stepping : 1 >> >> >>> microcode : 0x1 >> >> >>> cpu MHz : 2711.988 >> >> >>> cache size : 16384 KB >> >> >>> physical id : 0 >> >> >>> siblings : 1 >> >> >>> core id : 0 >> >> >>> cpu cores : 1 >> >> >>> apicid : 0 >> >> >>> initial apicid : 0 >> >> >>> fpu : yes >> >> >>> fpu_exception : yes >> >> >>> cpuid level : 11 >> >> >>> wp : yes >> >> >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >> >> >>> mca >> >> >>> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc >> >> >>> rep_good >> >> >>> nopl xtopology pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic >> >> >>> popcnt aes >> >> >>> hypervisor lahf_lm arat tpr_shadow vnmi flexpriority ept vpid >> >> >>> bogomips : 5423.97 >> >> >>> clflush size : 64 >> >> >>> cache_alignment : 64 >> >> >>> address sizes : 40 bits physical, 48 bits virtual >> >> >>> power management: >> >> >>> >> >> >>> journalctl -b on host0 shows that libvirt complains about NUMA >> >> >>> configuration: >> >> >>> >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: libvirt >> >> >>> version: 2.0.0, package: 10.el7_3.4 (CentOS BuildSystem >> >> >>> <http://bugs.centos.org <http://bugs.centos.org/>>;, 2017-01-17-23 <tel:2017-01-17-23>:37:48, c1bm.rdu2.centos.org <http://c1bm.rdu2.centos.org/>) >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: port >> >> >>> 2(vnet0) entered disabled state >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: device vnet0 >> >> >>> left >> >> >>> promiscuous mode >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kernel: ovirtmgmt: port >> >> >>> 2(vnet0) entered disabled state >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: >> >> >>> hostname: >> >> >>> lago-basic-suite-master-host0.lago.local >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: Unable >> >> >>> to >> >> >>> read from monitor: Connection reset by peer >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 libvirtd[12888]: >> >> >>> internal >> >> >>> error: qemu unexpectedly closed the monitor: >> >> >>> 2017-02-07T11:33:23.058571Z >> >> >>> qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 6 7 >> >> >>> 8 9 >> >> >>> 10 11 12 13 14 15 >> >> >>> >> >> >>> 2017-02-07T11:33:23.058826Z qemu-kvm: warning: All CPU(s) up to >> >> >>> maxcpus >> >> >>> should be described in NUMA config >> >> >>> >> >> >>> qemu-kvm: >> >> >>> /builddir/build/BUILD/qemu-2.6.0/target-i386/kvm.c:1736: kvm_put_msrs: >> >> >>> Assertion `ret == n' failed. >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 NetworkManager[657]: >> >> >>> <info> >> >> >>> [1486467203.1025] device (vnet0): state change: disconnected -> >> >> >>> unmanaged >> >> >>> (reason 'unmanaged') [30 10 3] >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 kvm[22059]: 0 guests now >> >> >>> active >> >> >>> Feb 07 06:33:23 lago-basic-suite-master-host0 systemd-machined[22044]: >> >> >>> Machine qemu-1-vm0 terminated. >> >> >>> >> >> >>> Thanks, >> >> >>> Ondra >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Devel mailing list >> >> >>> Devel(a)ovirt.org <mailto:Devel@ovirt.org> >> >> >>> http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Eyal Edri >> >> >> Associate Manager >> >> >> RHV DevOps >> >> >> EMEA ENG Virtualization R&D >> >> >> Red Hat Israel >> >> >> >> >> >> phone: +972-9-7692018 <tel:%2B972-9-7692018> >> >> >> irc: eedri (on #tlv #rhev-dev #rhev-integ) >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Devel mailing list >> >> > Devel(a)ovirt.org <mailto:Devel@ovirt.org> >> >> > http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel> >> > >> > >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org <mailto:Devel@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel> > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org <mailto:Devel@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel> >