AMD EPYC IBPB is deprecated in 4.3. The deprecated CPUs (cpus variable, that entire list) are: https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/s... So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and Opteron G1-3. If you have those, you need to change it to a supported type while it's in 4.2 still. Greg On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: > We just updated our engine to 4.3, but when I tried to update one of our > AMD EPYC hosts it could not activate with the error: > > Host vmc2h2 moved to Non-Operational state as host CPU type is not > supported in this cluster compatibility version or is not supported at all. > > Relevant (I think) parts from the the engine log: > > (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not > find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53), > flags: > 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca' > 2019-02-06 17:23:58,527-08 INFO > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START, > SetVdsStatusVDSCommand(HostName = vmc2h2, > SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53', > status='NonOperational', > nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER' > > > From virsh -r capabilities: > > <cpu> > <arch>x86_64</arch> > <model>EPYC-IBPB</model> > <vendor>AMD</vendor> > <microcode version='134222375'/> > <topology sockets='1' cores='32' threads='2'/> > <feature name='ht'/> > <feature name='osxsave'/> > <feature name='xsaves'/> > <feature name='cmp_legacy'/> > <feature name='extapic'/> > <feature name='skinit'/> > <feature name='wdt'/> > <feature name='tce'/> > <feature name='topoext'/> > <feature name='perfctr_core'/> > <feature name='perfctr_nb'/> > <feature name='invtsc'/> > <pages unit='KiB' size='4'/> > <pages unit='KiB' size='2048'/> > <pages unit='KiB' size='1048576'/> > </cpu> > > I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD > and moving the host into it, but it failed to move it into that cluster > with a similar error about an unsupported CPU (for some reason it also made > me clear the additional kernel options as well, we use 1gb hugepages). I > have not yet tried removing the host entirely and adding it as part of > creating the new cluster. > > We have been/are using a database change to update the 4.2 cluster level > to include EPYC support with the following entries (can post the whole > query if needed): > 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC > IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64 > > We have been running 4.2 with this for awhile. We did apply the same > changes after the 4.3 update, but only for the 4.2 cluster level. We only > used the AMD EPYC IBPB model. > > Reverting the host back to 4.2 allows it to activate and run normally. > > Anyone have any ideas as to why it can't seem to find the cpu type? > > Thanks, > > Ryan Bullock > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYS... > -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

On Thu, Feb 7, 2019 at 11:31 AM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: > That would explain it. > > Would removing the host and then reinstalling it under a new 4.3 cluster > work without having to set the entire old cluster into maintenance to > change the cpu? Then I could just restart VM's into the new cluster as we > transition to minimize downtime. > @Simone Tiraboschi <stirabos(a)redhat.com&gt; or @Ryan Barry <rbarry(a)redhat.com&gt; ?

> > Thanks for the info! > Glad to help :) Greg > > Ryan > > On Thu, Feb 7, 2019 at 7:56 AM Greg Sheremeta <gshereme(a)redhat.com&gt; > wrote: > >> AMD EPYC IBPB is deprecated in 4.3. >> The deprecated CPUs (cpus variable, that entire list) are: >> >> https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/s... >> >> So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and >> Opteron G1-3. If you have those, you need to change it to a supported type >> while it's in 4.2 still. >> >> Greg >> >> On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: >> >>> We just updated our engine to 4.3, but when I tried to update one of >>> our AMD EPYC hosts it could not activate with the error: >>> >>> Host vmc2h2 moved to Non-Operational state as host CPU type is not >>> supported in this cluster compatibility version or is not supported at all. >>> >>> Relevant (I think) parts from the the engine log: >>> >>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not >>> find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53), >>> flags: >>> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca' >>> 2019-02-06 17:23:58,527-08 INFO >>> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] >>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START, >>> SetVdsStatusVDSCommand(HostName = vmc2h2, >>> SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53', >>> status='NonOperational', >>> nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER' >>> >>> >>> From virsh -r capabilities: >>> >>> <cpu> >>> <arch>x86_64</arch> >>> <model>EPYC-IBPB</model> >>> <vendor>AMD</vendor> >>> <microcode version='134222375'/> >>> <topology sockets='1' cores='32' threads='2'/> >>> <feature name='ht'/> >>> <feature name='osxsave'/> >>> <feature name='xsaves'/> >>> <feature name='cmp_legacy'/> >>> <feature name='extapic'/> >>> <feature name='skinit'/> >>> <feature name='wdt'/> >>> <feature name='tce'/> >>> <feature name='topoext'/> >>> <feature name='perfctr_core'/> >>> <feature name='perfctr_nb'/> >>> <feature name='invtsc'/> >>> <pages unit='KiB' size='4'/> >>> <pages unit='KiB' size='2048'/> >>> <pages unit='KiB' size='1048576'/> >>> </cpu> >>> >>> I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD >>> and moving the host into it, but it failed to move it into that cluster >>> with a similar error about an unsupported CPU (for some reason it also made >>> me clear the additional kernel options as well, we use 1gb hugepages). I >>> have not yet tried removing the host entirely and adding it as part of >>> creating the new cluster. >>> >>> We have been/are using a database change to update the 4.2 cluster >>> level to include EPYC support with the following entries (can post the >>> whole query if needed): >>> 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC >>> IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64 >>> >>> We have been running 4.2 with this for awhile. We did apply the same >>> changes after the 4.3 update, but only for the 4.2 cluster level. We only >>> used the AMD EPYC IBPB model. >>> >>> Reverting the host back to 4.2 allows it to activate and run normally. >>> >>> Anyone have any ideas as to why it can't seem to find the cpu type? >>> >>> Thanks, >>> >>> Ryan Bullock >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYS... >>> >> >> >> -- >> >> GREG SHEREMETA >> >> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX >> >> Red Hat NA >> >> <https://www.redhat.com/> >> >> gshereme(a)redhat.com IRC: gshereme >> <https://red.ht/sig> >> > -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

On Thu, Feb 7, 2019 at 6:52 PM Simone Tiraboschi <stirabos(a)redhat.com&gt; wrote: > > > For an hosted-engine cluster we have a manual workaround procedure > documented here: > https://bugzilla.redhat.com/show_bug.cgi?id=1672859#c1 > > I managed to upgrade my Epyc cluster with those steps. I made new cluster with Epyc CPU Type and cluster already in 4.3 level. Starting engine in new cluster complained something about not finding vm with that uuid but it still started engine fine. When all nodes were in new cluster I still couldn't upgrade old cluster because engine was complaining that couple of VM's couldn't be upgraded (something to do with custom level). I moved them to new cluster too. Had to just change networks to management for the move. After that I could upgrade old cluster to Epyc and 4.3 level. Then I just moved VM's and nodes back (same steps but backwards). After that you can remove the extra cluster and raise datacenter to 4.3 level. -Juhani

This procedure worked for our HE, which is on Skylake. I think I have a process that should work for moving our EPYC clusters to 4.3. If it works this weekend I will post it for others. Ryan On Thu, Feb 7, 2019 at 12:06 PM Simone Tiraboschi <stirabos(a)redhat.com&gt; wrote: > > > On Thu, Feb 7, 2019 at 7:15 PM Juhani Rautiainen < > juhani.rautiainen(a)gmail.com&gt; wrote: > >> >> >> On Thu, Feb 7, 2019 at 6:52 PM Simone Tiraboschi <stirabos(a)redhat.com&gt; >> wrote: >> >>> >>> >>> For an hosted-engine cluster we have a manual workaround procedure >>> documented here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1672859#c1 >>> >>> >> I managed to upgrade my Epyc cluster with those steps. I made new >> cluster with Epyc CPU Type and cluster already in 4.3 level. Starting >> engine in new cluster complained something about not finding vm with that >> uuid but it still started engine fine. When all nodes were in new cluster I >> still couldn't upgrade old cluster because engine was complaining that >> couple of VM's couldn't be upgraded (something to do with custom level). I >> moved them to new cluster too. Had to just change networks to management >> for the move. After that I could upgrade old cluster to Epyc and 4.3 level. >> Then I just moved VM's and nodes back (same steps but backwards). After >> that you can remove the extra cluster and raise datacenter to 4.3 level. >> >> -Juhani >> > > > Thanks for the report! > We definitively have to figure out a better upgrade flow when a cluster > CPU change is required/advised. >

On Sat, Feb 9, 2019 at 7:43 PM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: > > So I tried making a new cluster with a 4.2 compatibility level and moving one of my EPYC hosts into it. I then updated the host to 4.3 and switched the cluster version 4.3 + set cluster cpu to the new AMD EPYC IBPD SSBD (also tried plain AMD EPYC). It still fails to make the host operational complaining that 'CPU type is not supported in this cluster compatibility version or is not supported at all'. > When I did this with Epyc I made new cluster wth 4.3 level and Epyc CPU. And then moved the nodes to it. Maybe try that? I also had to move couple of VM's to new cluster because old cluster couldn't upgrade with those. When nodes and couple problem VM's were in new cluster I could upgrade old cluster to new level. -Juhani

Got a host activated! 1. Update host to 4.3 2. rm /var/cache/libvirt/qemu/capabilities/*.xml 3. systemctl restart libvirtd 4. Activate host Seems like some kind of stuck state going from 4.2 -> 4.3 Hope this helps someone else. On Sat, Feb 9, 2019 at 1:12 PM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: > I tried that too, but it still complains about an unsupported CPU in the > new cluster. Even if I leave the cluster level at 4.2, if I update the host > to 4.3 it can't activate under a 4.2 cluster. > Makes me think something changed in how it verifies the CPU support and > for some reason it is not liking my EPYC systems. > > On Sat, Feb 9, 2019 at 10:18 AM Juhani Rautiainen < > juhani.rautiainen(a)gmail.com&gt; wrote: > >> On Sat, Feb 9, 2019 at 7:43 PM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: >> > >> > So I tried making a new cluster with a 4.2 compatibility level and >> moving one of my EPYC hosts into it. I then updated the host to 4.3 and >> switched the cluster version 4.3 + set cluster cpu to the new AMD EPYC IBPD >> SSBD (also tried plain AMD EPYC). It still fails to make the host >> operational complaining that 'CPU type is not supported in this cluster >> compatibility version or is not supported at all'. >> > >> When I did this with Epyc I made new cluster wth 4.3 level and Epyc >> CPU. And then moved the nodes to it. Maybe try that? I also had to >> move couple of VM's to new cluster because old cluster couldn't >> upgrade with those. When nodes and couple problem VM's were in new >> cluster I could upgrade old cluster to new level. >> >> -Juhani >> >

That would explain it. Would removing the host and then reinstalling it under a new 4.3 cluster work without having to set the entire old cluster into maintenance to change the cpu? Then I could just restart VM's into the new cluster as we transition to minimize downtime. Thanks for the info! Ryan On Thu, Feb 7, 2019 at 7:56 AM Greg Sheremeta <gshereme(a)redhat.com&gt; wrote: > AMD EPYC IBPB is deprecated in 4.3. > The deprecated CPUs (cpus variable, that entire list) are: > > https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/s... > > So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and > Opteron G1-3. If you have those, you need to change it to a supported type > while it's in 4.2 still. > > Greg > > On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: > >> We just updated our engine to 4.3, but when I tried to update one of our >> AMD EPYC hosts it could not activate with the error: >> >> Host vmc2h2 moved to Non-Operational state as host CPU type is not >> supported in this cluster compatibility version or is not supported at all. >> >> Relevant (I think) parts from the the engine log: >> >> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could not >> find server cpu for server 'vmc2h2' (745a14c6-9d31-48a4-9566-914647d83f53), >> flags: >> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca' >> 2019-02-06 17:23:58,527-08 INFO >> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] >> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START, >> SetVdsStatusVDSCommand(HostName = vmc2h2, >> SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53', >> status='NonOperational', >> nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER' >> >> >> From virsh -r capabilities: >> >> <cpu> >> <arch>x86_64</arch> >> <model>EPYC-IBPB</model> >> <vendor>AMD</vendor> >> <microcode version='134222375'/> >> <topology sockets='1' cores='32' threads='2'/> >> <feature name='ht'/> >> <feature name='osxsave'/> >> <feature name='xsaves'/> >> <feature name='cmp_legacy'/> >> <feature name='extapic'/> >> <feature name='skinit'/> >> <feature name='wdt'/> >> <feature name='tce'/> >> <feature name='topoext'/> >> <feature name='perfctr_core'/> >> <feature name='perfctr_nb'/> >> <feature name='invtsc'/> >> <pages unit='KiB' size='4'/> >> <pages unit='KiB' size='2048'/> >> <pages unit='KiB' size='1048576'/> >> </cpu> >> >> I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB SSBD >> and moving the host into it, but it failed to move it into that cluster >> with a similar error about an unsupported CPU (for some reason it also made >> me clear the additional kernel options as well, we use 1gb hugepages). I >> have not yet tried removing the host entirely and adding it as part of >> creating the new cluster. >> >> We have been/are using a database change to update the 4.2 cluster level >> to include EPYC support with the following entries (can post the whole >> query if needed): >> 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC >> IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64 >> >> We have been running 4.2 with this for awhile. We did apply the same >> changes after the 4.3 update, but only for the 4.2 cluster level. We only >> used the AMD EPYC IBPB model. >> >> Reverting the host back to 4.2 allows it to activate and run normally. >> >> Anyone have any ideas as to why it can't seem to find the cpu type? >> >> Thanks, >> >> Ryan Bullock >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYS... >> > > > -- > > GREG SHEREMETA > > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > > Red Hat NA > > <https://www.redhat.com/> > > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> > _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FMDXG35JGXX...

Hey Steven, Including just the cpuFlags, since the output is pretty verbose. Let me know if you need anything else from the output. Without avic=1 (Works Fine): "cpuFlags": "fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca,model_Opteron_G3,model_Opteron_G2,model_kvm32,model_kvm64,model_Westmere,model_Nehalem,model_Conroe,model_EPYC-IBPB,model_Opteron_G1,model_SandyBridge,model_qemu32,model_Penryn,model_pentium2,model_486,model_qemu64,model_cpu64-rhel6,model_EPYC,model_pentium,model_pentium3" With avic=1 (Problem Configuration): "cpuFlags": "fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca" Flags stay the same, but with avic=1 no models are shown as supported. Also, I opened this bug https://bugzilla.redhat.com/show_bug.cgi?id=1675030 regarding the avic=1 setting seemingly requiring the x2apic flag. -Ryan On Sun, Feb 17, 2019 at 5:22 AM Steven Rosenberg <srosenbe(a)redhat.com&gt; wrote: > Dear Ryan Bullock, > > I am currently looking at this issue: > > > https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYS... > > We would like more information concerning the CPU Flags (even though you > included them in your engine log dump above). > > Could you run the following command on the same host running: AMD > EPYC-IBPB > > vdsm-client Host getCapabilities > > Please send me the output, especially the CPU Flags. > > Thank you in advance for your help. > > With Best Regards. > > Steven Rosenberg. > > > > On Thu, Feb 7, 2019 at 6:35 PM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: > >> That would explain it. >> >> Would removing the host and then reinstalling it under a new 4.3 cluster >> work without having to set the entire old cluster into maintenance to >> change the cpu? Then I could just restart VM's into the new cluster as we >> transition to minimize downtime. >> >> Thanks for the info! >> >> Ryan >> >> On Thu, Feb 7, 2019 at 7:56 AM Greg Sheremeta <gshereme(a)redhat.com&gt; >> wrote: >> >>> AMD EPYC IBPB is deprecated in 4.3. >>> The deprecated CPUs (cpus variable, that entire list) are: >>> >>> https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/s... >>> >>> So, *-IBRS [IBRS-SSBD is still ok], Epyc IBPB, Conroe, Penryn, and >>> Opteron G1-3. If you have those, you need to change it to a supported type >>> while it's in 4.2 still. >>> >>> Greg >>> >>> On Thu, Feb 7, 2019 at 1:11 AM Ryan Bullock <rrb3942(a)gmail.com&gt; wrote: >>> >>>> We just updated our engine to 4.3, but when I tried to update one of >>>> our AMD EPYC hosts it could not activate with the error: >>>> >>>> Host vmc2h2 moved to Non-Operational state as host CPU type is not >>>> supported in this cluster compatibility version or is not supported at all. >>>> >>>> Relevant (I think) parts from the the engine log: >>>> >>>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [ee51a70] Could >>>> not find server cpu for server 'vmc2h2' >>>> (745a14c6-9d31-48a4-9566-914647d83f53), flags: >>>> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,constant_tsc,art,rep_good,nopl,nonstop_tsc,extd_apicid,amd_dcm,aperfmperf,eagerfpu,pni,pclmulqdq,monitor,ssse3,fma,cx16,sse4_1,sse4_2,movbe,popcnt,aes,xsave,avx,f16c,rdrand,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,skinit,wdt,tce,topoext,perfctr_core,perfctr_nb,bpext,perfctr_l2,cpb,hw_pstate,sme,retpoline_amd,ssbd,ibpb,vmmcall,fsgsbase,bmi1,avx2,smep,bmi2,rdseed,adx,smap,clflushopt,sha_ni,xsaveopt,xsavec,xgetbv1,clzero,irperf,xsaveerptr,arat,npt,lbrv,svm_lock,nrip_save,tsc_scale,vmcb_clean,flushbyasid,decodeassists,pausefilter,pfthreshold,avic,v_vmsave_vmload,vgif,overflow_recov,succor,smca' >>>> 2019-02-06 17:23:58,527-08 INFO >>>> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] >>>> (EE-ManagedThreadFactory-engineScheduled-Thread-82) [7f6d4f0d] START, >>>> SetVdsStatusVDSCommand(HostName = vmc2h2, >>>> SetVdsStatusVDSCommandParameters:{hostId='745a14c6-9d31-48a4-9566-914647d83f53', >>>> status='NonOperational', >>>> nonOperationalReason='CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER' >>>> >>>> >>>> From virsh -r capabilities: >>>> >>>> <cpu> >>>> <arch>x86_64</arch> >>>> <model>EPYC-IBPB</model> >>>> <vendor>AMD</vendor> >>>> <microcode version='134222375'/> >>>> <topology sockets='1' cores='32' threads='2'/> >>>> <feature name='ht'/> >>>> <feature name='osxsave'/> >>>> <feature name='xsaves'/> >>>> <feature name='cmp_legacy'/> >>>> <feature name='extapic'/> >>>> <feature name='skinit'/> >>>> <feature name='wdt'/> >>>> <feature name='tce'/> >>>> <feature name='topoext'/> >>>> <feature name='perfctr_core'/> >>>> <feature name='perfctr_nb'/> >>>> <feature name='invtsc'/> >>>> <pages unit='KiB' size='4'/> >>>> <pages unit='KiB' size='2048'/> >>>> <pages unit='KiB' size='1048576'/> >>>> </cpu> >>>> >>>> I also tried creating a new 4.3 cluster, set to the AMD EPYC IPBDB >>>> SSBD and moving the host into it, but it failed to move it into that >>>> cluster with a similar error about an unsupported CPU (for some reason it >>>> also made me clear the additional kernel options as well, we use 1gb >>>> hugepages). I have not yet tried removing the host entirely and adding it >>>> as part of creating the new cluster. >>>> >>>> We have been/are using a database change to update the 4.2 cluster >>>> level to include EPYC support with the following entries (can post the >>>> whole query if needed): >>>> 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC >>>> IBPB:svm,nx,ibpb,model_EPYC:EPYC-IBPB:x86_64 >>>> >>>> We have been running 4.2 with this for awhile. We did apply the same >>>> changes after the 4.3 update, but only for the 4.2 cluster level. We only >>>> used the AMD EPYC IBPB model. >>>> >>>> Reverting the host back to 4.2 allows it to activate and run normally. >>>> >>>> Anyone have any ideas as to why it can't seem to find the cpu type? >>>> >>>> Thanks, >>>> >>>> Ryan Bullock >>>> _______________________________________________ >>>> Users mailing list -- users(a)ovirt.org >>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>> oVirt Code of Conduct: >>>> https://www.ovirt.org/community/about/community-guidelines/ >>>> List Archives: >>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYS... >>>> >>> >>> >>> -- >>> >>> GREG SHEREMETA >>> >>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX >>> >>> Red Hat NA >>> >>> <https://www.redhat.com/> >>> >>> gshereme(a)redhat.com IRC: gshereme >>> <https://red.ht/sig> >>> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/FMDXG35JGXX... >> >