On Wed, Feb 02, 2022 at 01:06:40PM +0000, Richard W.M. Jones wrote:
On Wed, Feb 02, 2022 at 01:32:14PM +0100, Lucia Jelinkova wrote:
> Hi,
>
> The list should contain more items. Could you please try to create a
> new cluster using UI, set the compatibility level to 4.6,
> architecture to x86_64 and check the CPU Type dropdown again?
I created a new DC "Custom", checked compat level is 4.6.
Within that, created a new Cluster "Custom", arch is x86_64, and ..
you're right! It was a UI issue of some kind because now I see the
scrollbar on the right and there are many more machine types.
I selected AMD EPYC, so let's see how it goes creating a host.
Sadly that didn't fix the problem, I'm still getting:
Host ovirt4410 moved to Non-Operational state as host CPU type is not supported in this
cluster compatibility version or is not supported at all
and in engine.log:
2022-02-02 13:35:01,713Z ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-44) [310af602]
EVENT_ID: CPU_TYPE_UNSUPPORTED_IN_THIS_CLUSTER_VERSION(156), Host ovirt4410-host moved to
Non-Operational state as host CPU type is not supported in this cluster compatibility
version or is not supported at all
Mousing over the status, it says it's missing 'model_EPYC' and 'svm'
flags. The first one is weird because the emulated model in the guest
is:
model name : AMD EPYC-Rome Processor
The second one is correct because I guess KVM is masking this flag
from the guest:
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 mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid
extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec
xgetbv1 xsaves clzero xsaveerptr wbnoinvd arat umip rdpid arch_capabilities
Is there not any way to ignore this stuff? I really don't care that
this node which is only going to be used for testing won't run VMs
optimally. For comparison VMware ESXi 7 also raised minimum CPU types
substantially, but offers a simple (unsupported) opt out.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org