You updated Proxmox, rebooted, and now a virtual machine will not start. If the host has a recent AMD processor, this page is probably your answer.
Check this first
Look in the host’s boot log for this line:
kernel: RDSEED32 is broken. Disabling the corresponding CPUID bit.If it is there, you have the fault described below. If it is not, this page is not your problem and it is worth looking elsewhere before changing anything.
What is actually happening
Recent AMD processors from the Zen 5 family have a hardware bug in an instruction called RDSEED, which the processor uses to produce random numbers. AMD documents it in its security bulletin for the RDSEED issue.
On kernel 6.17.9 and newer, Linux spots the faulty instruction and switches it off, which is the log line above. That is the right thing for the kernel to do.
The trouble is what it does to your virtual machines. A guest set up with a CPU type that tells the guest RDSEED is available, such as EPYC or EPYC-v4, now asks for something the host has just switched off, and refuses to start. According to the Proxmox release notes, which record this as a known issue from 9.1, that is the whole mechanism.
So nothing is corrupted and nothing is lost. The machine is refusing to start rather than starting broken, which is the better of the two.
Three ways to fix it, best first
1. Install the microcode update
This is the real fix, because it corrects the processor’s behaviour rather than working around it.
The correction ships in the amd64-microcode package, which is in the Proxmox repositories. The release notes give the version that fixes it as 3.20251202.1~bpo13+1 or newer.
There is a catch, and it is the reason this fault confuses people. The microcode update only takes effect if the machine’s BIOS already contains the fix for a separate AMD issue called Entrysign, covered in AMD’s Entrysign bulletin.
If your BIOS is too old, installing the package appears to work but the update is quietly refused at boot, and you will see a line like this instead:
kernel: microcode: No sha256 digest for patch ID: 0xb002161 foundIf you see that line, go to fix 2.
2. Update the BIOS
This is what the release notes recommend when the microcode update is refused. A current BIOS from your motherboard or system maker includes the Entrysign fix, after which the microcode package can do its job, and fix 1 then works.
Updating a BIOS carries its own small risk and varies by maker, so follow your hardware maker’s own instructions for it rather than anyone else’s.
3. Change the virtual machine’s CPU type
If you need the machine running tonight and cannot update the BIOS yet, change the affected virtual machine to a CPU type that does not advertise the faulty instruction. The release notes name two that work: host, or the Proxmox default, x86-64-v2-AES.
This gets the guest starting again immediately. It is a workaround rather than a fix, because the processor still has the fault underneath, so treat it as a way through the evening rather than a permanent answer.
If none of those apply yet
The release notes also describe a last-resort option for machines whose maker has not yet published a BIOS containing the Entrysign fix. It involves disabling a microcode check, which is a security trade-off rather than a free fix, and the right answer for most people is to use fix 3 until the BIOS update appears. If you are considering the last resort, read the full entry in the Proxmox release notes first, because it is not something to do on the strength of a summary.
Before your next upgrade
If you run Zen 5 hardware and have not hit this yet, you will the next time the kernel moves past 6.17.9. Updating the BIOS now, while nothing is broken and you are not in a hurry, turns this from an evening of confusion into a non-event.