Most of the attention around Proxmox VE 9 went on the jump from 8, which was a Debian version change and deserved the care. Less has been written about what happened after, and two point releases have landed since.
If you upgraded early and have not touched it since, you are on 9.0 and have missed both.
The one that can stop virtual machines starting
This is the item worth reading even if you skip the rest.
Recent AMD processors from the Zen 5 family have a hardware bug in an instruction called RDSEED, which the processor uses to generate random numbers. AMD documents it in its own security bulletin.
On kernel 6.17.9 and newer, Linux notices the broken instruction and switches it off. That is the correct thing for the kernel to do, and it has an awkward consequence: a virtual machine configured with a CPU type that advertises that instruction to its guest will now refuse to start.
The symptom is a virtual machine that simply will not boot after an otherwise clean upgrade, with a line in the boot log saying RDSEED32 is broken. Disabling the corresponding CPUID bit.
There are three ways out, as the Proxmox release notes set out. Install the updated microcode package, which is the proper fix. Update the machine’s BIOS, which delivers the same fix at a lower level. Or change the affected virtual machine to a CPU type that does not expose the instruction.
If you run Zen 5 hardware, check this before you upgrade rather than after.
What 9.2 added
The headline is automatic load balancing. The Cluster Resource Scheduler can now move high-availability guests between nodes on its own, based on live resource usage rather than a fixed rule. For a single-machine home setup this changes nothing. For anyone running three nodes in a cupboard, it is the most significant addition in either release.
Alongside it: the networking stack gained WireGuard and BGP fabrics, custom CPU models can now be created and edited in the web interface instead of by hand, and the high-availability stack can be disarmed and re-armed across the whole cluster for maintenance.
That last one has its own trap. If you disarm high availability while guests are still migrating and then start an upgrade, the upgrade can stall on the pve-ha-manager package. Keeping the stack armed through the upgrade avoids it, and re-arming an already-stuck upgrade lets it continue.
What 9.1 added
The most interesting change for home users is that containers can now be created from OCI images. OCI is the standard format container images are distributed in, which means the enormous catalogue of existing images becomes a source of Proxmox containers rather than something you needed a separate Docker host to use.
It also moved to kernel 6.17 as the default, which is the change that brings the AMD issue above into play.
The one that only affects rented servers
If your Proxmox runs on a machine hosted at OVH, 9.2 adds a memtest86+ boot entry, and on OVH servers managed by proxmox-boot-tool but not installed from OVH’s own template, the boot process can select memtest86+ instead of Proxmox.
The machine then boots into a memory tester and stays there. Harmless, and alarming if you are not expecting it. Not relevant to a machine at home, which is most readers here, but worth knowing if you also run a rented box.
Should you bother
If you run a single machine and it is doing its job, 9.1 and 9.2 are not urgent. Nothing here is a security emergency and the biggest features are for clusters.
Two exceptions. If you have Zen 5 hardware, deal with the microcode issue on your own schedule rather than discovering it during an unrelated upgrade. And if you run Windows guests on Intel hosts with Virtualization-based Security enabled, the release notes record those freezing intermittently at 100% CPU, which is worth knowing before you spend an evening blaming your own configuration.
Everything on this page comes from Proxmox’s own per-release notes, and the full release history carries the complete list for every version rather than just the items likely to affect a home setup.