Beim Versuch einen neuen physischen OLVM Host (Oracle Linux 8.10) mit einer AMD EPCY 9xx5 (Zen 5 Generation) in einen OLVM Cluster mit OLVM 4.5.5-1.57 hinzuzufügen, erhält man in der OLVM Web-UI (nach einem Reboot des OLVM Hosts) den Status „Not Operational“. Wirft man einen Blick in den Eventlog, findet man dann diese Fehlermeldung:
Da diese nur bedingt hilfreich ist, geht es weiter in Engine-Log am OLVM Manager (Admin) Host, wo man folgende Zeilen findet:
2025-10-16 10:37:36,037Z ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-82) [27da630a] EVENT_ID: CPU_TYPE_UNSUPPORTED_IN_THIS_CLUSTER_VERSION(156), Host kvm-server-01 moved to Non-Operational state as host CPU type is not supported in this cluster compatibility version or is not supported at all
2025-10-16 10:37:36,046Z ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-82) [27da630a] EVENT_ID: CPU_TYPE_UNSUPPORTED_IN_THIS_CLUSTER_VERSION(156), Host kvm-server-01 moved to Non-Operational state as host CPU type is not supported in this cluster compatibility version or is not supported at allAm OLVM Host selbst, fördert ein Blick ins vdsm.log folgendes hervor:
2025-10-16 10:37:26,397+0000 ERROR (jsonrpc/1) [root] Error while getting domain capabilities (machinetype:75)
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/vdsm/common/cache.py", line 25, in __call__
return self.cache[args]
KeyError: ()
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/vdsm/machinetype.py", line 73, in _get_domain_capabilities
domcaps = conn.getDomainCapabilities(None, arch, None, virt_type, 0)
File "/usr/lib/python3.6/site-packages/vdsm/common/libvirtconnection.py", line 114, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/vdsm/common/function.py", line 78, in wrapper
return func(inst, *args, **kwargs)
File "/usr/lib64/python3.6/site-packages/libvirt.py", line 4524, in getDomainCapabilities
raise libvirtError('virConnectGetDomainCapabilities() failed')
libvirt.libvirtError: internal error: missing 'nvram-template' in '/usr/share/qemu/firmware/44-edk2-ovmf-cc-stateless.json'
2025-10-16 10:37:26,398+0000 ERROR (jsonrpc/1) [root] Error while getting CPU features: no domain capabilities found (machinetype:171)
2025-10-16 10:37:26,410+0000 ERROR (jsonrpc/1) [root] Error while getting domain capabilities (machinetype:75)
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/vdsm/common/cache.py", line 25, in __call__
return self.cache[args]
KeyError: ()
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/vdsm/machinetype.py", line 73, in _get_domain_capabilities
domcaps = conn.getDomainCapabilities(None, arch, None, virt_type, 0)
File "/usr/lib/python3.6/site-packages/vdsm/common/libvirtconnection.py", line 114, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/vdsm/common/function.py", line 78, in wrapper
return func(inst, *args, **kwargs)
File "/usr/lib64/python3.6/site-packages/libvirt.py", line 4524, in getDomainCapabilities
raise libvirtError('virConnectGetDomainCapabilities() failed')
libvirt.libvirtError: internal error: missing 'nvram-template' in '/usr/share/qemu/firmware/44-edk2-ovmf-cc-stateless.json'
2025-10-16 10:37:26,410+0000 ERROR (jsonrpc/1) [root] Error while getting CPU models: no domain capabilities found (machinetype:104)Nach einiger Sucht stößt man in MOS auf folgenden Artikel: OLVM: Host Non-Operational with the Message: CPU_TYPE_UNSUPPORTED_IN_THIS_CLUSTER_VERSION (Doc ID 3056480.1). Damit kommt man schon ein Stück weiter, weil es anscheinend einen Fehler im edk2-ovmf gibt, dass man auf Version 20240227-5 downgraden soll. In dem Artikel wird von einem einmaligen Downgrade gesprochen, anscheinend gibt es aber inzwischen eine neuere Version, so dass in unserem Fall ein zweimaliges Downgrade notwendig war:
dnf downgrade edk2-ovmf
dnf downgrade edk2-ovmf
dnf versionlock edk2-ovmf
systemctl restart vdsmdNachdem dem Downgrade muss man das Aktualisieren von edk2-ovmf verhindern (versionlock), da man sonst beim nächsten Patching wieder vor dem gleichen Problem steht. Danach ist ein Restart vom VDSMD notwendig.
Lieder war das nicht alles – wie der MOS Artikel suggeriert. Zumindest im Fall von AMD EPYC 9xx5 (Zen 5) CPUs, muss man für das Kernelmodule eine Option für Netztet Virtualization aktivieren. Dazu muss man in der Datei /etc/modprobe.d/kvm.conf folgende Zeilen aktivieren (den Kommentar am Zeilenanfang entfernen):
options kvm_amd nested=1Jetzt kann man den Host erneut im OLVM Admin Web-UI zum Cluster ohne weitere Probleme hinzufügen.
Während der Suche im Internet weisst einiges darauf hin, dass auch AMD EPYC 9xx4 (Zen 4) sowie noch andere CPUs betroffen sein dürften. Dies haben wir aus Mangel an passender Hardware nicht verifizieren können.
Offene Fragen
Wenn ein Problem im edk2-ovmf offensichtlich seit längerer Zeit bekannt ist, warum wird es dann nicht behoben?
Wann darf man den Versionlock auf edk2-ovmf wieder entfernen?