Re: difference between CPU server and client family
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms. But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU. You can run this on the host to check what’s detected: [root]# vdsm-client Host getCapabilities Sent from my iPhone On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> wrote:
I get this output: "cpuFlags": "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32", "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz", "cpuSockets": "1", "cpuSpeed": "4499.377", "cpuThreads": "12", "deferred_preallocation": true, Does this says something to you? Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> wrote:
qemu CPUs are mostly mapping to microarchitectures, for this one there’s excessive number of details at [1] :) but yours seems to be CofeeLake (8th gen) which is not really supported yet in that version. Well, you didn’t say anything about what your version is, so I don’t know for sure… It’s usually a compromise between what the hardware has and what has been implemented just yet Thanks, michal [1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)
On 8 Dec 2020, at 17:09, jb <jonbae77@gmail.com> wrote:
I get this output:
"cpuFlags": "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32", "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz", "cpuSockets": "1", "cpuSpeed": "4499.377", "cpuThreads": "12", "deferred_preallocation": true,
Does this says something to you?
Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> <mailto:jonbae77@gmail.com> wrote:
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PI...
Thanks Michal for the explanation. I will dive in this article and see if I understand it :-). I use here the latest 4.4.3.12 Version. So I can hope, that newer version will support my CPUs better :). Best regards Jonathan Am 08.12.20 um 19:12 schrieb Michal Skrivanek:
qemu CPUs are mostly mapping to microarchitectures, for this one there’s excessive number of details at [1] :)
but yours seems to be CofeeLake (8th gen) which is not really supported yet in that version. Well, you didn’t say anything about what your version is, so I don’t know for sure…
It’s usually a compromise between what the hardware has and what has been implemented just yet
Thanks, michal
[1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server) <https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)>
On 8 Dec 2020, at 17:09, jb <jonbae77@gmail.com <mailto:jonbae77@gmail.com>> wrote:
I get this output:
"cpuFlags": "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32", "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz", "cpuSockets": "1", "cpuSpeed": "4499.377", "cpuThreads": "12", "deferred_preallocation": true,
Does this says something to you?
Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> wrote:
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PI... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/>
On 9 Dec 2020, at 09:09, jb <jonbae77@gmail.com> wrote:
Thanks Michal for the explanation. I will dive in this article and see if I understand it :-).
I use here the latest 4.4.3.12 Version. So I can hope, that newer version will support my CPUs better :).
not sure. 4.5 cluster level adds IceLake which is Gen10, that should work with CentOS 8.3 newly. It could be that your particular model is something in between… Either way, if you really do need every feature from the CPU and you’re willing to sacrifice migration compatibility you can always use CPU host passthrough. Then it ignores any compatibility and just uses everything it can(everything that KVM supports) from the underlying CPU
Best regards
Jonathan
Am 08.12.20 um 19:12 schrieb Michal Skrivanek:
qemu CPUs are mostly mapping to microarchitectures, for this one there’s excessive number of details at [1] :)
but yours seems to be CofeeLake (8th gen) which is not really supported yet in that version. Well, you didn’t say anything about what your version is, so I don’t know for sure…
It’s usually a compromise between what the hardware has and what has been implemented just yet
Thanks, michal
[1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server) <https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)>
On 8 Dec 2020, at 17:09, jb <jonbae77@gmail.com <mailto:jonbae77@gmail.com>> wrote:
I get this output:
"cpuFlags": "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32", "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz", "cpuSockets": "1", "cpuSpeed": "4499.377", "cpuThreads": "12", "deferred_preallocation": true,
Does this says something to you?
Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> <mailto:jonbae77@gmail.com> wrote:
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PI... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/>
Am 09.12.20 um 14:42 schrieb Michal Skrivanek:
On 9 Dec 2020, at 09:09, jb <jonbae77@gmail.com <mailto:jonbae77@gmail.com>> wrote:
Thanks Michal for the explanation. I will dive in this article and see if I understand it :-).
I use here the latest 4.4.3.12 Version. So I can hope, that newer version will support my CPUs better :).
not sure. 4.5 cluster level adds IceLake which is Gen10, that should work with CentOS 8.3 newly. It could be that your particular model is something in between…
Either way, if you really do need every feature from the CPU and you’re willing to sacrifice migration compatibility you can always use CPU host passthrough. Then it ignores any compatibility and just uses everything it can(everything that KVM supports) from the underlying CPU
No I don't need every feature. My concern was mostly, if I will have any performance downsides in normal scenarios.
Am 08.12.20 um 19:12 schrieb Michal Skrivanek:
qemu CPUs are mostly mapping to microarchitectures, for this one there’s excessive number of details at [1] :)
but yours seems to be CofeeLake (8th gen) which is not really supported yet in that version. Well, you didn’t say anything about what your version is, so I don’t know for sure…
It’s usually a compromise between what the hardware has and what has been implemented just yet
Thanks, michal
[1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server) <https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)>
On 8 Dec 2020, at 17:09, jb <jonbae77@gmail.com <mailto:jonbae77@gmail.com>> wrote:
I get this output:
"cpuFlags": "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32", "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz", "cpuSockets": "1", "cpuSpeed": "4499.377", "cpuThreads": "12", "deferred_preallocation": true,
Does this says something to you?
Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> wrote:
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PI... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/>
On 9 Dec 2020, at 15:16, jb <jonbae77@gmail.com> wrote:
Am 09.12.20 um 14:42 schrieb Michal Skrivanek:
On 9 Dec 2020, at 09:09, jb <jonbae77@gmail.com <mailto:jonbae77@gmail.com>> wrote:
Thanks Michal for the explanation. I will dive in this article and see if I understand it :-).
I use here the latest 4.4.3.12 Version. So I can hope, that newer version will support my CPUs better :).
not sure. 4.5 cluster level adds IceLake which is Gen10, that should work with CentOS 8.3 newly. It could be that your particular model is something in between…
Either way, if you really do need every feature from the CPU and you’re willing to sacrifice migration compatibility you can always use CPU host passthrough. Then it ignores any compatibility and just uses everything it can(everything that KVM supports) from the underlying CPU
No I don't need every feature. My concern was mostly, if I will have any performance downsides in normal scenarios.
A compromise makes sense then. Because on one hand you do not need compatibility with CPUs that you don’t have because they’re 10 years old, vs you’re not recompiling every application with the highest optimizations to use the latest greatest instructions…so…using whatever it detects is usually the best choice:)
Am 08.12.20 um 19:12 schrieb Michal Skrivanek:
qemu CPUs are mostly mapping to microarchitectures, for this one there’s excessive number of details at [1] :)
but yours seems to be CofeeLake (8th gen) which is not really supported yet in that version. Well, you didn’t say anything about what your version is, so I don’t know for sure…
It’s usually a compromise between what the hardware has and what has been implemented just yet
Thanks, michal
[1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server) <https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)>
On 8 Dec 2020, at 17:09, jb <jonbae77@gmail.com <mailto:jonbae77@gmail.com>> wrote:
I get this output:
"cpuFlags": "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32", "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz", "cpuSockets": "1", "cpuSpeed": "4499.377", "cpuThreads": "12", "deferred_preallocation": true,
Does this says something to you?
Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
> On 8 Dec 2020, at 10:52, jb <jonbae77@gmail.com> <mailto:jonbae77@gmail.com> wrote: >
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PI... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/>
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EBSLFMU5MPSZ67...
participants (3)
-
jb -
Michal Skrivanek -
Vinícius Ferrão