5:09 p.m.
Hi!
You are running oVirt nested inside KVM? Have you enabled nested
virtualization in KVM? Didn't see any mention of that in the thread.
That might explain the missing svm flag.
https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualizati...
-Juhani
On Wed, Feb 2, 2022 at 3:47 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
>
> 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
> _______________________________________________
> Users mailing list -- users(a)ovirt.org
> To unsubscribe send an email to users-leave(a)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/S2Q3M46GUGN...