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 Datei42-edk2-ovmf-cc.json
zu löschen auch eine leere Datei50-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.