10:26 a.m.
Hi,
I am currently building a new virtualization cluster with oVirt, using
AMD EPYC processors (AMD EPYC 7351P). At the moment I'm running oVirt
Node Version 4.2.3 @ CentOS 7.4.1708.
We have the situation that the processor type is recognized as "AMD
Opteron G3". With this type of instruction set the VMs are not able to
do AES in hardware, this results in poor performance in our case.
I found some information that tells me that this problem should be
solved with CentOS 7.5
--> <https://access.redhat.com/errata/RHEA-2018:1488>
My actual questions:
- Are there any further information about the AMD EPYC support?
- Any information about an update of the oVirt node to CentOS 7.5?
Greeting Tobias
3:52 a.m.
2018-05-20 17:26 GMT+02:00 Tobias Scheinert <tobias.scheinert(a)uni-ulm.de>:
Hi,
I am currently building a new virtualization cluster with oVirt, using AMD
EPYC processors (AMD EPYC 7351P). At the moment I'm running oVirt Node
Version 4.2.3 @ CentOS 7.4.1708.
We have the situation that the processor type is recognized as "AMD
Opteron G3". With this type of instruction set the VMs are not able to do
AES in hardware, this results in poor performance in our case.
I found some information that tells me that this problem should be solved
with CentOS 7.5
--> <https://access.redhat.com/errata/RHEA-2018:1488>
My actual questions:
- Are there any further information about the AMD EPYC support?
- Any information about an update of the oVirt node to CentOS 7.5?
About oVirt Node 4.2.3 @ CentOS 7.5 we are planning a respin this week.
Greeting Tobias
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
11:17 a.m.
Hi,
for any of you who wants AMD EPYC support right now (its a hack, not
proper tested!):
1) Make sure your node and your engine are running under RedHat/CentOS 7.5
[root@ovirt ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
2) Get your PostgreSQL credentials
less /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
3) Make the PostgreSQL libs available, so that we can start the
PostgreSQL client later.
echo '/opt/rh/rh-postgresql95/root/lib64/'
>/etc/ld.so.conf.d/postgresql_opt.conf
4) Become PostgreSQL user.
su - postgres
5) Connect to the PostgreSQL database.
/opt/rh/rh-postgresql95/root/bin/psql -h localhost -p 5432 -U engine
-W
6) Run the database update:
select fn_db_update_config_value('ServerCPUList',
'3:Intel Conroe Family:vmx,nx,model_Conroe:Conroe:x86_64; 4:Intel Penryn
Family:vmx,nx,model_Penryn:Penryn:x86_64; 5:Intel Nehalem
Family:vmx,nx,model_Nehalem:Nehalem:x86_64; 6:Intel Nehalem IBRS
Family:vmx,nx,spec_ctrl,model_Nehalem:Nehalem,+spec-ctrl:x86_64; 7:Intel Nehalem IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Nehalem:Nehalem,+spec-ctrl,+ssbd:x86_64; 8:Intel
Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64; 9:Intel Westmere IBRS
Family:aes,vmx,nx,spec_ctrl,model_Westmere:Westmere,+spec-ctrl:x86_64; 10:Intel Westmere
IBRS SSBD
Family:aes,vmx,nx,spec_ctrl,ssbd,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd:x86_64;
11:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64; 12:Intel
SandyBridge IBRS Family:vmx,nx,spec_ctrl,model_SandyBridge:SandyBridge,+spec-ctrl:x86_64;
13:Intel SandyBridge IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd:x86_64;
14:Intel Haswell-noTSX Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64; 15:Intel
Haswell-noTSX IBRS
Family:vmx,nx,spec_ctrl,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl:x86_64; 16:Intel
Haswell-noTSX IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd:x86_64;
17:Intel Haswell Family:vmx,nx,model_Haswell:Haswell:x86_64; 18:Intel Haswell IBRS
Family:vmx,nx,spec_ctrl,model_Haswell:Haswell,+spec-ctrl:x86_64; 19:Intel Haswell IBRS
SSBD Family:vmx,nx,spec_ctrl,ssbd,model_Haswell:Haswell,+spec-ctrl,+ssbd:x86_64; 20:Intel
Broadwell-noTSX Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64; 21:Intel
Broadwell-noTSX IBRS
Family:vmx,nx,spec_ctrl,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl:x86_64; 22:Intel
Broadwell-noTSX IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd:x86_64;
23:Intel Broadwell Family:vmx,nx,model_Broadwell:Broadwell:x86_64; 24:Intel Broadwell IBRS
Family:vmx,nx,spec_ctrl,model_Broadwell:Broadwell,+spec-ctrl:x86_64; 25:Intel Broadwell
IBRS SSBD Family:vmx,nx,spec_ctrl,ssbd,model_Broadwell:Broadwell,+spec-ctrl,+ssbd:x86_64;
26:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client:x86_64; 27:Intel
Skylake Client IBRS
Family:vmx,nx,spec_ctrl,model_Skylake-Client:Skylake-Client,+spec-ctrl:x86_64; 28:Intel
Skylake Client IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd:x86_64;
29:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server:x86_64; 30:Intel
Skylake Server IBRS
Family:vmx,nx,spec_ctrl,model_Skylake-Server:Skylake-Server,+spec-ctrl:x86_64; 31:Intel
Skylake Server IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd:x86_64;
2:AMD Opteron G1:svm,nx,model_Opteron_G1:Opteron_G1:x86_64; 3:AMD Opteron
G2:svm,nx,model_Opteron_G2:Opteron_G2:x86_64; 4:AMD Opteron
G3:svm,nx,model_Opteron_G3:Opteron_G3:x86_64; 5:AMD Opteron
G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64; 6:AMD Opteron
G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64; 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64;
8:AMD EPYC IBPB:svm,nx,ibpb,model_EPYC:EPYC,+ibpb:x86_64; 3:IBM
POWER8:powernv,model_POWER8:POWER8:ppc64; 4:IBM POWER9:powernv,model_POWER9:POWER9:ppc64;
2:IBM z114, z196:sie,model_z196-base:z196-base:s390x; 3:IBM zBC12,
zEC12:sie,model_zEC12-base:zEC12-base:s390x; 4:IBM z13s,
z13:sie,model_z13-base:z13-base:s390x; 5:IBM z14:sie,model_z14-base:z14-base:s390x;',
'4.2');
7) Exit PostgreSQL and the PostgreSQL user, restart the ovirt-engine
systemctl restart ovirt-engine
After that we are able to use the AMD EPYC processor model.
[root@virtual-machine ~]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 1
model name : AMD EPYC Processor
stepping : 2
microcode : 0x1000065
cpu MHz : 2399.998
cache size : 512 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
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 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good
nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt
aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw retpoline_amd vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap
clflushopt sha_ni xsaveopt xsavec xgetbv1 arat
bogomips : 4799.99
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management:
Keep in mind that next database update will overwrite the changes that
you made, so maybe apply this again.
Greeting Tobias
11:25 a.m.
2018-05-25 18:17 GMT+02:00 Tobias Scheinert <tobias.scheinert(a)uni-ulm.de>:
Hi,
for any of you who wants AMD EPYC support right now (its a hack, not
proper tested!):
Michal, can we backport https://bugzilla.redhat.com/show_bug.cgi?id=1517286
to 4.2 avoiding people to do an hack?
Tobias, just to be sure you noticed it, a respin of oVirt Node 4.2.3 absed
on CentOS 7.5 has been released this morning.
1) Make sure your node and your engine are running under RedHat/CentOS 7.5
[root@ovirt ~]# cat /etc/redhat-release
> CentOS Linux release 7.5.1804 (Core)
>
2) Get your PostgreSQL credentials
less /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
>
3) Make the PostgreSQL libs available, so that we can start the PostgreSQL
client later.
echo '/opt/rh/rh-postgresql95/root/lib64/' >/etc/ld.so.conf.d/postgresql_
> opt.conf
>
4) Become PostgreSQL user.
su - postgres
>
5) Connect to the PostgreSQL database.
/opt/rh/rh-postgresql95/root/bin/psql -h localhost -p 5432 -U engine -W
>
6) Run the database update:
select fn_db_update_config_value('ServerCPUList', '3:Intel Conroe
> Family:vmx,nx,model_Conroe:Conroe:x86_64; 4:Intel Penryn
> Family:vmx,nx,model_Penryn:Penryn:x86_64; 5:Intel Nehalem
> Family:vmx,nx,model_Nehalem:Nehalem:x86_64; 6:Intel Nehalem IBRS
> Family:vmx,nx,spec_ctrl,model_Nehalem:Nehalem,+spec-ctrl:x86_64; 7:Intel
> Nehalem IBRS SSBD Family:vmx,nx,spec_ctrl,ssbd,m
> odel_Nehalem:Nehalem,+spec-ctrl,+ssbd:x86_64; 8:Intel Westmere
> Family:aes,vmx,nx,model_Westmere:Westmere:x86_64; 9:Intel Westmere IBRS
> Family:aes,vmx,nx,spec_ctrl,model_Westmere:Westmere,+spec-ctrl:x86_64;
> 10:Intel Westmere IBRS SSBD Family:aes,vmx,nx,spec_ctrl,ss
> bd,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd:x86_64; 11:Intel
> SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64; 12:Intel
> SandyBridge IBRS Family:vmx,nx,spec_ctrl,model_
> SandyBridge:SandyBridge,+spec-ctrl:x86_64; 13:Intel SandyBridge IBRS
> SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd:x86_64;
> 14:Intel Haswell-noTSX Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64;
> 15:Intel Haswell-noTSX IBRS Family:vmx,nx,spec_ctrl,model_
> Haswell-noTSX:Haswell-noTSX,+spec-ctrl:x86_64; 16:Intel Haswell-noTSX
> IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd:x86_64;
> 17:Intel Haswell Family:vmx,nx,model_Haswell:Haswell:x86_64; 18:Intel
> Haswell IBRS Family:vmx,nx,spec_ctrl,model_Haswell:Haswell,+spec-ctrl:x86_64;
> 19:Intel Haswell IBRS SSBD Family:vmx,nx,spec_ctrl,ssbd,m
> odel_Haswell:Haswell,+spec-ctrl,+ssbd:x86_64; 20:Intel Broadwell-noTSX
> Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64; 21:Intel
> Broadwell-noTSX IBRS Family:vmx,nx,spec_ctrl,model_
> Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl:x86_64; 22:Intel
> Broadwell-noTSX IBRS SSBD Family:vmx,nx,spec_ctrl,ssbd,m
> odel_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd:x86_64; 23:Intel
> Broadwell Family:vmx,nx,model_Broadwell:Broadwell:x86_64; 24:Intel
> Broadwell IBRS Family:vmx,nx,spec_ctrl,model_
> Broadwell:Broadwell,+spec-ctrl:x86_64; 25:Intel Broadwell IBRS SSBD
> Family:vmx,nx,spec_ctrl,ssbd,model_Broadwell:Broadwell,+spec-ctrl,+ssbd:x86_64;
> 26:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client:x86_64;
> 27:Intel Skylake Client IBRS Family:vmx,nx,spec_ctrl,model_
> Skylake-Client:Skylake-Client,+spec-ctrl:x86_64; 28:Intel Skylake Client
> IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd:x86_64;
> 29:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server:x86_64;
> 30:Intel Skylake Server IBRS Family:vmx,nx,spec_ctrl,model_
> Skylake-Server:Skylake-Server,+spec-ctrl:x86_64; 31:Intel Skylake Server
> IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd:x86_64;
> 2:AMD Opteron G1:svm,nx,model_Opteron_G1:Opteron_G1:x86_64; 3:AMD
> Opteron G2:svm,nx,model_Opteron_G2:Opteron_G2:x86_64; 4:AMD Opteron
> G3:svm,nx,model_Opteron_G3:Opteron_G3:x86_64; 5:AMD Opteron
> G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64; 6:AMD Opteron
> G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64; 7:AMD
> EPYC:svm,nx,model_EPYC:EPYC:x86_64; 8:AMD EPYC
> IBPB:svm,nx,ibpb,model_EPYC:EPYC,+ibpb:x86_64; 3:IBM
> POWER8:powernv,model_POWER8:POWER8:ppc64; 4:IBM
> POWER9:powernv,model_POWER9:POWER9:ppc64; 2:IBM z114,
> z196:sie,model_z196-base:z196-base:s390x; 3:IBM zBC12,
> zEC12:sie,model_zEC12-base:zEC12-base:s390x; 4:IBM z13s,
> z13:sie,model_z13-base:z13-base:s390x; 5:IBM
> z14:sie,model_z14-base:z14-base:s390x;', '4.2');
>
7) Exit PostgreSQL and the PostgreSQL user, restart the ovirt-engine
systemctl restart ovirt-engine
>
After that we are able to use the AMD EPYC processor model.
[root@virtual-machine ~]# cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 23
> model : 1
> model name : AMD EPYC Processor
> stepping : 2
> microcode : 0x1000065
> cpu MHz : 2399.998
> cache size : 512 KB
> physical id : 0
> siblings : 8
> core id : 0
> cpu cores : 8
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> 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 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm art rep_good nopl extd_apicid eagerfpu pni pclmulqdq
> ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand
> hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse
> 3dnowprefetch osvw retpoline_amd vmmcall fsgsbase bmi1 avx2 smep bmi2
> rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 arat
> bogomips : 4799.99
> TLB size : 1024 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management:
>
Keep in mind that next database update will overwrite the changes that you
made, so maybe apply this again.
Greeting Tobias
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
6:22 a.m.
On 25 May 2018, at 18:25, Sandro Bonazzola
<sbonazzo(a)redhat.com> wrote:
2018-05-25 18:17 GMT+02:00 Tobias Scheinert <tobias.scheinert(a)uni-ulm.de
<mailto:tobias.scheinert@uni-ulm.de>>:
Hi,
for any of you who wants AMD EPYC support right now (its a hack, not proper tested!):
Michal, can we backport https://bugzilla.redhat.com/show_bug.cgi?id=1517286
<https://bugzilla.redhat.com/show_bug.cgi?id=1517286> to 4.2 avoiding people to do
an hack?
not without breaking compatibility with existing 4.2
It requires EL 7.5 qemu which was not around at the time of 4.2 GA. It is used in master
right now, and will be in oVirt 4.3 in 4.3 cluster level.
Tobias, just to be sure you noticed it, a respin of oVirt Node 4.2.3 absed on CentOS 7.5
has been released this morning.
1) Make sure your node and your engine are running under RedHat/CentOS 7.5
[root@ovirt ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
2) Get your PostgreSQL credentials
less /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
3) Make the PostgreSQL libs available, so that we can start the PostgreSQL client later.
echo '/opt/rh/rh-postgresql95/root/lib64/'
>/etc/ld.so.conf.d/postgresql_opt.conf
4) Become PostgreSQL user.
su - postgres
5) Connect to the PostgreSQL database.
/opt/rh/rh-postgresql95/root/bin/psql -h localhost -p 5432 -U engine -W
6) Run the database update:
select fn_db_update_config_value('ServerCPUList', '3:Intel Conroe
Family:vmx,nx,model_Conroe:Conroe:x86_64; 4:Intel Penryn
Family:vmx,nx,model_Penryn:Penryn:x86_64; 5:Intel Nehalem
Family:vmx,nx,model_Nehalem:Nehalem:x86_64; 6:Intel Nehalem IBRS
Family:vmx,nx,spec_ctrl,model_Nehalem:Nehalem,+spec-ctrl:x86_64; 7:Intel Nehalem IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Nehalem:Nehalem,+spec-ctrl,+ssbd:x86_64; 8:Intel
Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64; 9:Intel Westmere IBRS
Family:aes,vmx,nx,spec_ctrl,model_Westmere:Westmere,+spec-ctrl:x86_64; 10:Intel Westmere
IBRS SSBD
Family:aes,vmx,nx,spec_ctrl,ssbd,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd:x86_64;
11:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64; 12:Intel
SandyBridge IBRS Family:vmx,nx,spec_ctrl,model_SandyBridge:SandyBridge,+spec-ctrl:x86_64;
13:Intel SandyBridge IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd:x86_64;
14:Intel Haswell-noTSX Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64; 15:Intel
Haswell-noTSX IBRS
Family:vmx,nx,spec_ctrl,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl:x86_64; 16:Intel
Haswell-noTSX IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd:x86_64;
17:Intel Haswell Family:vmx,nx,model_Haswell:Haswell:x86_64; 18:Intel Haswell IBRS
Family:vmx,nx,spec_ctrl,model_Haswell:Haswell,+spec-ctrl:x86_64; 19:Intel Haswell IBRS
SSBD Family:vmx,nx,spec_ctrl,ssbd,model_Haswell:Haswell,+spec-ctrl,+ssbd:x86_64; 20:Intel
Broadwell-noTSX Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64; 21:Intel
Broadwell-noTSX IBRS
Family:vmx,nx,spec_ctrl,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl:x86_64; 22:Intel
Broadwell-noTSX IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd:x86_64;
23:Intel Broadwell Family:vmx,nx,model_Broadwell:Broadwell:x86_64; 24:Intel Broadwell IBRS
Family:vmx,nx,spec_ctrl,model_Broadwell:Broadwell,+spec-ctrl:x86_64; 25:Intel Broadwell
IBRS SSBD Family:vmx,nx,spec_ctrl,ssbd,model_Broadwell:Broadwell,+spec-ctrl,+ssbd:x86_64;
26:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client:x86_64; 27:Intel
Skylake Client IBRS
Family:vmx,nx,spec_ctrl,model_Skylake-Client:Skylake-Client,+spec-ctrl:x86_64; 28:Intel
Skylake Client IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd:x86_64;
29:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server:x86_64; 30:Intel
Skylake Server IBRS
Family:vmx,nx,spec_ctrl,model_Skylake-Server:Skylake-Server,+spec-ctrl:x86_64; 31:Intel
Skylake Server IBRS SSBD
Family:vmx,nx,spec_ctrl,ssbd,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd:x86_64;
2:AMD Opteron G1:svm,nx,model_Opteron_G1:Opteron_G1:x86_64; 3:AMD Opteron
G2:svm,nx,model_Opteron_G2:Opteron_G2:x86_64; 4:AMD Opteron
G3:svm,nx,model_Opteron_G3:Opteron_G3:x86_64; 5:AMD Opteron
G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64; 6:AMD Opteron
G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64; 7:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64;
8:AMD EPYC IBPB:svm,nx,ibpb,model_EPYC:EPYC,+ibpb:x86_64; 3:IBM
POWER8:powernv,model_POWER8:POWER8:ppc64; 4:IBM POWER9:powernv,model_POWER9:POWER9:ppc64;
2:IBM z114, z196:sie,model_z196-base:z196-base:s390x; 3:IBM zBC12,
zEC12:sie,model_zEC12-base:zEC12-base:s390x; 4:IBM z13s,
z13:sie,model_z13-base:z13-base:s390x; 5:IBM z14:sie,model_z14-base:z14-base:s390x;',
'4.2');
7) Exit PostgreSQL and the PostgreSQL user, restart the ovirt-engine
systemctl restart ovirt-engine
After that we are able to use the AMD EPYC processor model.
[root@virtual-machine ~]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 1
model name : AMD EPYC Processor
stepping : 2
microcode : 0x1000065
cpu MHz : 2399.998
cache size : 512 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
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 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good
nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt
aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw retpoline_amd vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap
clflushopt sha_ni xsaveopt xsavec xgetbv1 arat
bogomips : 4799.99
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management:
Keep in mind that next database update will overwrite the changes that you made, so maybe
apply this again.
It will not get overwritten on every update, only in exceptional cases like the 4.2.3.7
CVE fix adding new CPU types.
Also host cpu passthrough would give you that as well without any hacks. You would lose
live migration, though. we’re working on removing that limitation, but currently that’s
the way it is.
Thanks,
michal
Greeting Tobias
_______________________________________________
Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-leave(a)ovirt.org
<mailto:users-leave@ovirt.org>
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com <mailto:sbonazzo@redhat.com>
<https://red.ht/sig>
<https://redhat.com/summit>
4:15 a.m.
Hello,
About hardware support, are there any expected drawbacks to using the latest stable kernel
from elrepo.org? If so, is there a better/supported way to use a 4.xx series kernel in
oVirt Node while we wait for the next major version of RHEL/CentOS?
Our Benchmarks show a performance uplift with newer kernels and we would like to take
advantage of that without harming stability, if at all possible.
9:17 a.m.
This is, from what I can see, the last update Skylake-server in Ovirt: Am I correct to
understand that this was never backported to 4.2?
I'm at 4.2.7 and would like to use Skylake-Server, but seems to be still unavailable.
As you mention backporting, I assume it is/will be in 4.3?
And as 4.3 release isn't anytime soon, is it recommended to apply Tobias
"hack", or should I attempt to use some type of cpu-passthrough for now (though,
I don't see a trivial way to enable this either).
Best regards, Mikael
8:33 a.m.
I was curious, I have an AMD Threadripper (2970wx). Do you know where Ovirt is grepping or
other to get the info needed to use the cpu type? I assume lscpu is possibly where it gets
it and is just matching? Id like to be able to test this on a threadripper.
10:15 a.m.
On 2018-11-30 09:33, Darin Schmidt wrote:
I was curious, I have an AMD Threadripper (2970wx). Do you know
where
Ovirt is grepping or other to get the info needed to use the cpu type?
I assume lscpu is possibly where it gets it and is just matching? Id
like to be able to test this on a threadripper.
IIRC, this is coming in 4.3
2213
days inactive
2407
days old
10 comments
7 participants
participants (7)
-
Alex McWhirter -
Darin Schmidt -
Michal Skrivanek -
Mikael Öhman -
pousaduarte＠gmail.com -
Sandro Bonazzola -
Tobias Scheinert