libvirtError: internal error: unknown feature amd-sev-es beim Upgrade auf OLVM 4.3 / OL 7.9 mit Intel CPUs

updated on

Ausgangssituation: Auf einer vorhandenen OLVM 4.3 Installation unter OL 7.7 wurde am OLVM Management Host ein Upgrade auf Oracle Linux 7.9 mit anschließendem engine-setup durchgeführt und danach der OLVM Management Host restartet. Bis zu diesem Zeitpunkt gab es noch kein Problem.

Danach wurde über das Web-UI des OLVM Management Hosts ein Upgrade der OLVM Server angestoßen. Sobald dieses fertiggestellt war, sind die OLVM Server im Status unassigned oder NotResponsive stehen geblieben. Bei den OLVM Servern handelt es sich um Server mit Intel Xeon CPUs.

Problemanalyse

Die Prüfung auf den OLVM Servern ergab für VDSN folgendes:

systemctl status vdsmd -l
vdsmd.service - Virtual Desktop Server Manager
  Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: enabled)
  Active: active (running) since Fri 2024-06-07 15:05:33 CEST; 10min ago
  Process: 3239 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS)
  Main PID: 3319 (vdsmd)
   Tasks: 38
   Memory: 67.0M
   CGroup: /system.slice/vdsmd.service
           └─3319 /usr/bin/python2 /usr/share/vdsm/vdsmd

Jun 07 15:15:35 olvm10.example.com vdsm[3319]: ERROR Internal server error
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 345, in _handle_request
    res = method(**params)
  File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 198, in _dynamicMethod
    result = fn(*methodArgs)
  File "<string>", line 2, in getCapabilities
  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method
    ret = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1371, in getCapabilities
    c = caps.get()
  File "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 95, in get
    machinetype.compatible_cpu_models())
  File "/usr/lib/python2.7/site-packages/vdsm/common/cache.py", line 43, in __call__
    value = self.func(*args)
  File "/usr/lib/python2.7/site-packages/vdsm/machinetype.py", line 142, in compatible_cpu_models
    all_models = domain_cpu_models(c, arch, cpu_mode)
  File "/usr/lib/python2.7/site-packages/vdsm/machinetype.py", line 97, in domain_cpu_models
    domcaps = conn.getDomainCapabilities(None, arch, None, virt_type, 0)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 131, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 94, in wrapper
    return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4048, in getDomainCapabilities
    if ret is None: raise libvirtError ('virConnectGetDomainCapabilities() failed', conn=self)
libvirtError: internal error: unknown feature amd-sev-es

Auch der libvirtd lieferte einen Fehler, der sich mit folgenden Befehlen reproduzieren läßt:

vdsm-client Host getCapabilities
virsh domcapabilities

Ein Check der aktualisierten Packages liess uns vermuten, dass der Fehler durch das Upgrade des
Pakets OVMF-1.7.0-5.el7.noarch verursacht wurde.

Ein Check des Pakets liefert die installierten Dateien

yum info OVMF-1.7.0-5.el7.noarch
rpm -ql OVMF-1.7.0-5.el7.noarch

Wir haben dann mit grep nach dem String aus dem Fehler gesucht

grep "amd-sev-es" /usr/share/qemu/firmware/*.json

und dabei die Datei

42-edk2-ovmf-cc.json

gefunden, die den String amd-sev-es aus dem Fehler enthielten.

Hier gibt es mehrere Einträge, die ebenfalls zu Fehlern führten und so haben wir am Ende einfach
die Datei /usr/share/qemu/firmware/42-edk2-ovmf-cc.json gelöscht, nachdem diese Datei in
der früherer Version des OVMF-Pakets auch nicht vorhanden war. Bei dem File handelt es sich um einen Konfiguration des SEV (Secure Encrypted Virtualization) Funktionalität von aktuellen AMD CPUs. Dies ist für Intel CPUs natürlich nicht relevant.

Das hat den Fehler behoben. Zur Sicherheit haben wir den Host nochmals über das OLVM Web-UI neu
gestartet. Danach ist der Host ohne Probleme wieder online gekommen und konnte auch wieder VMs
hosten.

Es dürfte sich dabei um den folgenden Bug handeln:

  • Red Hat Bugzilla Bug 1061562, der eigentlich für RHEL 8.5 gemeldet wurde. Anscheinend wurde der Fehler mit dem letzten Update von OVMF auch in Oracle Linux 7.9 / OLVM 4.3 zurückportiert. Offiziell sollte die AMD SEV Unterstützung erst mit OLVM 4.5 Einzug halten.
    Das Problem tritt nur auf, wenn man KEINE AMD CPUs einsetzt. Alternativ kann man statt die Datei 42-edk2-ovmf-cc.json zu löschen auch eine leere Datei 50-edk2-ovmf-cc.json im gleichen Verzeichnis anlegen.

Das zeigt wieder einmal, wie wichtig es ist, ein Test-Environment zu haben. In einem Produktionsenvironment könnte dieser Fehler zu längeren Downtimes führen.