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>