Wer Veeam Backup & Replication als Veeam Software Appliance auf einem Host mit AMD-EPYC-Prozessor betreibt, sollte den nächsten Neustart nicht unbeaufsichtigt laufen lassen. Im Knowledge-Base-Artikel KB4960 vom 4. November 2026 warnt Veeam, dass die virtuelle Maschine ab Version 13.1 nach einem Reboot sporadisch nicht mehr hochfährt – auch dann, wenn zuvor ein Update einen neuen Kernel installiert hat. Der Start bricht früh mit einer Kernel Panic ab:

Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9

Die VM bleibt danach liegen, bis jemand sie von Hand neu startet. Je nach Hypervisor ist die Meldung laut Veeam nur über eine serielle Konsole oder im Ereignisprotokoll des Hypervisors zu sehen. Einen Fix gibt es nicht, nur Workarounds.

Betroffene Versionen und Prozessoren

Betroffen ist die Software Appliance ab Version 13.1, also die Variante, bei der Veeam Backup & Replication auf einem von Veeam gepflegten Linux läuft. Als Prozessoren nennt der Hersteller die AMD EPYC 7262, 7302 und 7F72 – ausdrücklich als Beispiele („including“), die Liste ist also nicht abschließend. Alle drei Modelle gehören zur EPYC-7002-Serie „Rome“ mit Zen-2-Architektur, die AMD 2019 vorgestellt hat. Warum gerade diese Prozessoren betroffen sind, erklärt Veeam nicht. Hat die Appliance einmal erfolgreich gebootet, sind laut KB keine weiteren Fehler zu erwarten, und der Betrieb von Backup & Replication ist nicht beeinträchtigt.

Was dahintersteckt: Jitterentropy im FIPS-Modus

Ursache ist nach Veeams Angaben ein Gesundheitstest, den der Linux-Kernel der Appliance im FIPS-Modus in der frühen Bootphase ausführt. Geprüft wird Jitterentropy, laut Kernel-Quelltext ein nicht-physikalischer echter Zufallszahlengenerator auf Basis von CPU-Jitter. Er gewinnt Entropie aus winzigen Schwankungen in der Ausführungszeit und liest dafür einen hochauflösenden Zeitgeber aus. Bevor er Daten liefert, prüft er seine Quelle mit statistischen Tests nach der NIST-Vorgabe SP 800-90B, darunter ein Repetition Count Test und ein Adaptive Proportion Test. Mit anderen Worten: Der Kernel will beim Start sicherstellen, dass die Rauschquelle für seine Zufallszahlen tatsächlich genug Zufall liefert.

Die 9 am Ende der Fehlermeldung steht im Kernel für den Fehlercode JENT_EHEALTH, kommentiert mit „Health test failed during initialization“. Was danach passiert, hängt am FIPS-Modus. Im aktuellen Mainline-Quelltext sieht die Stelle so aus:

if (ret) {
	/* Handle permanent health test error */
	if (fips_enabled)
		panic("jitterentropy: Initialization failed with host not compliant with requirements: %d\n", ret);
	jent_testing_exit();
	pr_info("jitterentropy: Initialization failed with host not compliant with requirements: %d\n", ret);
	return -EFAULT;
}

Ohne FIPS-Modus schreibt der Kernel also nur eine Meldung ins Log und verzichtet auf den Jitter-Generator. Mit FIPS-Modus hält er das System an und meldet, der Host erfülle die Anforderungen nicht. Veeams Appliances basieren auf einer angepassten Rocky-Linux-Distribution; für die verwandte Infrastructure Appliance nennt der Hersteller als Basis Rocky Linux from CIQ mit FIPS-140-3-validierten Paketen. Für die Kernelversion der Software Appliance gibt es nach Angaben des Herstellers noch keine Korrektur; das Problem stamme aus dem Linux-Kernel selbst.

Mit der RDSEED-Schwachstelle, die AMD am 23. Oktober 2025 als AMD-SB-7055 veröffentlichte, bringt Veeam den Fehler nicht in Verbindung. Auch die Eckdaten passen nicht zusammen: AMD-SB-7055 betrifft Prozessoren der Zen-5-Generation wie die EPYC-Serien 4005 und 9005, die von Veeam genannten Modelle gehören zur deutlich älteren Zen-2-Generation. Zudem stützt sich Jitterentropy auf Zeitmessungen und nicht auf den Hardware-Befehl RDSEED.

Nahinfrarot-Aufnahme eines geöffneten AMD Epyc 7702 aus der Rome-Generation mit großem I/O-Die in der Mitte und acht kleineren Core-Dies

Bild: Geöffneter AMD Epyc 7702 (Engineering Sample) aus der Rome-Generation, zu der auch die von Veeam genannten Modelle gehören – Foto: Fritzchens Fritz / Wikimedia Commons, CC0

Heikel: Das Kernel-Update gegen CVE-2026-98432 steht an

Brisant wird das Problem durch ein anderes Update. Am 6. November 2026 hat Veeam in KB4966 bestätigt, dass die Software Appliance 13.1 von der kritischen Kernel-Lücke CVE-2026-98432 im TCP/IPv4-Verbindungsaufbau (CVSS 9,8) betroffen ist, bis der Kernel aktualisiert wurde – Details zur Lücke in unserem Artikel zur TCP-Schwachstelle. Ein Update mit dem korrigierten Kernel 5.14.0-570.60.1+27.2.el9_6_ciq liegt seit dem 2. November im Veeam-Repository.

In der Standardkonfiguration installiert der Veeam Updater Pflicht-Updates automatisch am nächsten Sonntag um 14 Uhr, bezogen auf die Zeitzone des Backup-Servers. Für das seit dem 2. November verfügbare Update fällt dieser Termin auf Sonntag, den 8. November 2026, sofern es nicht vorher von Hand eingespielt wurde. Damit der neue Kernel aktiv wird, muss die Appliance neu starten; laut Veeam-Dokumentation startet der Updater den Server bei Bedarf selbst neu. Auf einem betroffenen EPYC-Host kann die automatische Installation also mit einer VM enden, die nicht zurückkommt – womöglich am Sonntagnachmittag, ohne dass jemand zuschaut. Liegenlassen sollte man das Sicherheitsupdate trotzdem nicht.

Was du jetzt tun solltest

1. Prozessor des Hosts prüfen. Entscheidend ist die CPU des Virtualisierungshosts, auf dem die Appliance läuft. Auf einem Linux-Host mit KVM, etwa Proxmox VE, und auf VMware ESXi (per SSH) zeigen diese Befehle die Modellbezeichnung:

# Linux-/KVM-Host, z. B. Proxmox VE
lscpu | grep "Model name"

# VMware ESXi
esxcli hardware cpu list | grep -m1 Brand

Auf einem Hyper-V-Host hilft PowerShell:

Get-CimInstance Win32_Processor | Select-Object Name

Steht dort eines der genannten Modelle, fällt dein Host unter die Warnung. Bei anderen EPYC-Prozessoren gibt es keine Entwarnung, weil Veeams Liste nicht vollständig ist. BIOS-, Firmware- oder Microcode-Updates nennt Veeam nicht als Abhilfe, ebenso wenig einen Kernel-Parameter.

2. Wenn möglich umziehen. Veeams erste Empfehlung lautet, die Appliance auf einem Host mit einem anderen Prozessor neu bereitzustellen.

3. Automatische Installation abschalten. Geht das nicht, sollen Admins laut KB die automatischen Updates deaktivieren. In der Backup-&-Replication-Konsole geht das über das Hauptmenü unter „Updates > Update Settings“, Reiter „General“: Als „Maintenance window“ „None“ wählen. In der Web-Oberfläche liegt die Einstellung unter „Configuration > Update Settings“. Wichtig: Auch dann installiert der Updater Pflicht-Updates zwangsweise, sobald die „Compliance deadline“ erreicht ist – standardmäßig nach 30 Tagen, verlängerbar auf bis zu 90 Tage. Laufen in dem Moment Backup- oder Restore-Jobs, schlagen sie fehl. Plane die manuelle Installation also vor Ablauf dieser Frist ein.

4. Updates manuell und unter Aufsicht einspielen. In der Veeam Host Management Console unter „Updates > Check for updates“ nach Updates suchen, sie auswählen und mit „Install Updates Now“ installieren. Behalte während des Neustarts die Konsole der VM im Blick oder richte vorher eine serielle Konsole ein, damit du die Panic-Meldung überhaupt siehst.

5. Bei einer Kernel Panic kalt neu starten. Die VM muss ausgeschaltet und wieder eingeschaltet werden; ein Neustart aus dem Gastbetriebssystem heraus behebt den Zustand laut Veeam nicht. Je nach Hypervisor zum Beispiel so:

# Proxmox VE: VM hart stoppen und wieder starten
qm stop <vmid> && qm start <vmid>

# VMware ESXi: VM-ID ermitteln, dann aus- und einschalten
vim-cmd vmsvc/getallvms
vim-cmd vmsvc/power.off <vmid>
vim-cmd vmsvc/power.on <vmid>
# Hyper-V
Stop-VM -Name "Veeam-Appliance" -TurnOff
Start-VM -Name "Veeam-Appliance"

Wann eine Korrektur für den Appliance-Kernel kommt, lässt Veeam offen. Wer betroffen ist, sollte KB4960 im Auge behalten.

Quellen

Bildnachweis