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