Proxmox VE 9.3 Upgrade Guide for a Rolling Cluster

Proxmox VE 9.3 is reportedly landing within weeks, and the smartest move is to treat it as a routine point release instead of a big event. Read the roadmap to separate rumoured features from confirmed ones, borrow the lessons that the 9.1 and 9.2 upgrades taught, and run a handful of small checks first so the upgrade finishes inside a maintenance window rather than a 3 a.m. incident. If you have a four-node cluster holding up your lab or your production workloads, the sequence below is the one I would follow.

Key Takeaways

• Read the board: the roadmap at pve.proxmox.com/roadmap is the only source of truth for what is planned versus rumoured.
• Trust the changelog: per-version changes live in the official changelog, not in a forum thread.
• Back up what you can restore: an untested backup is a hope, not a safety net.
• Upgrade one node at a time: a rolling upgrade keeps the cluster alive if something breaks.
• Grab the console first: out-of-band access is what saves you when a new kernel drops a driver.

How to read the Proxmox roadmap

Proxmox issues major versions periodically and follows each major with several point releases that patch and update. Each major release is supported for roughly three years, which is why point releases stay focused on stability instead of new features. Keep that in mind when you open the roadmap: a feature you love will usually land in a major, while 9.3 is mostly about the kernel, the packages, and security.

The roadmap page lists features across categories with a status column, and the status is the whole game. Items tagged "done" have shipped, items tagged "in progress" are being worked on, and items tagged "rumor" are ideas someone floated rather than commitments. Before you get excited about anything on the board, check whether it is attached to a major version or quietly sitting in the "rumor" bucket where it will not make 9.3.

The changelog is the other half of the picture. While the roadmap tells you what is coming, the changelog at pve.proxmox.com/doc/changelog.html tells you what actually shipped in a specific version, including every package bump and bug fix. Read both: the roadmap sets your expectations, and the changelog tells you what you will actually get when you run the upgrade.

Decide up front whether 9.3 is required for your setup. If you run Ceph and the release notes promise a bug fix that affects your cluster, jump on it. If you are just running a handful of VMs and containers, it is perfectly fine to wait for 9.4 and let the early adopters shake out any issues. There is no penalty for being a few point releases behind, as long as you stay inside the support window.

Which features are real and which are just whispers?

The temptation when a new release is around is to plan your architecture around a feature you saw mentioned once. Resist it, and learn to triage the sources by confidence:

Where you see it	What it really means	What you should do
Roadmap tagged "rumor"	An idea, not committed to any release	Ignore it for planning
Roadmap "in progress"	Being worked on, but not shipped	Worth a glance, not a dependency
Changelog entry for 9.3	Something that actually shipped	Plan around it
Release notes	Intentional behaviour or config changes	Read before touching anything
Forum post with no status	Someone's wish or a misread	Treat as gossip

The release notes deserve a dedicated pass because that is where the surprises live. A point release can quietly change a default, drop a deprecated option, or ask for a config tweak after reboot. That is exactly why the next section exists.

Lessons from the 9.1 and 9.2 upgrades

Point releases almost always upgrade cleanly, and the ones that did not go smoothly shared a handful of causes. The first is drivers and firmware on older hardware: a newer kernel in the point release sometimes lacks the module your NIC, RAID controller, or GPU needs, and that shows up as a node that boots but cannot talk to the cluster. The second is storage backends — a newer ZFS or LVM-thin package can behave differently on an existing dataset, so watch the release notes for anything mentioning your storage. The third, and the one that costs the most sleep, is skipping the test.

A fourth lesson is to write down the baseline before you start: note the current version, the storage layout, and any custom tweaks on each node. When the upgrade goes sideways, that note is the fastest way back to a known-good state.

Here is a small gotcha that trips people up every single release: after the upgrade, the web UI can still show the old version number for a few minutes. That is the browser caching the frontend bundles, not the node lying. Run pveversion -v on the node itself to get the truth, and open the UI in an incognito window to clear the cosmetic confusion.

Another lesson is to read the release notes for deprecations before you touch production. If 9.3 removes an option you rely on in a VM config or a network bridge, you will find out the hard way. A five-minute read now saves an hour of recovery later.

How to prepare a cluster upgrade so it stays boring

The boring upgrade is the one you have already de-risked. Run these checks on every node before you start.

Back up something you can actually restore

A backup you have never restored is a hope, not a safety net. Take a fresh backup of every VM and container, then actually spin one up from it to confirm the restore path works. If you are using Automated Backups with Proxmox Backup Server, verify the snapshots are on disk and, if you offsite them, that the sync jobs completed. A restore test takes maybe ten minutes and it is the difference between "minor hiccup" and "we lost the weekend".

Map the window and the rolling order

Work out how long the window is and in what order you will touch nodes. On a four-node cluster, budget roughly 15 to 20 minutes per node for the package install plus the reboot, which puts a full rolling upgrade closer to an hour of window. Here is the honest tradeoff: a rolling upgrade is safer because the cluster stays online if a node misbehaves, but it only works if you have enough spare capacity to migrate every VM and container off a node before you upgrade it. On a tightly packed cluster that means either leaving headroom in your capacity plan or accepting a reduced workload during the window.

Grab the console before you start

If a new kernel drops the driver for your management NIC, the node will boot into a state where the web UI and SSH are dead. The only way in is the hardware console — IPMI, iDRAC, iLO, or a remote KVM. Check that access works before the upgrade, not during a failure, and treat remote KVM as worth the investment even for a homelab. If you have IPMI configured, you can sanity-check the BMC network settings with:

ipmitool lan print 1

If that command fails or returns nothing, sort out console access first. This single step is what turns a potential overnight outage into a five-minute fix.

Verify the repo, the kernel, and the disk space

The upgrade comes from whatever repository your sources.list points at, so confirm the candidate version before you commit. Check what apt is about to install:

apt-cache policy pve-manager

That shows the candidate version, which should be your 9.3 build. Then confirm the current state and free space:

pveversion -v
df -h / /var

Proxmox stores storage under /var, and a failed or interrupted upgrade can need headroom, so make sure both partitions have room. Do not mix the free community repository with the enterprise repository on the same node unless you know what you are doing; the two can point at different package versions and turn your upgrade into a dependency conflict. Pick one source and stick with it. If you manage a larger cluster, you can fold these checks into a runbook with Automate Proxmox VE with Ansible Full VM Playbooks so every node is verified the same way. You can also run a quick health sweep with the scripts from Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs to catch anything off before you begin.

Rolling the upgrade, node by node

With the checks done, upgrade one node at a time so the other nodes can keep your workloads alive. Start by confirming the cluster is healthy:

pvecm status
pvecm nodes

Then move every VM and container off the node you are about to upgrade. For a VM, online migration keeps it running:

qm migrate 100 pve02 --online 1

This assumes shared storage; for local-only storage you would add --with-local-disks. For a container, use the equivalent command against the target node:

pct migrate 200 pve02 --online 1

If High Availability is managing that resource, migrate it out of the way first so the manager does not fight you. Once the node is empty, upgrade it:

apt update
apt full-upgrade

Confirm the prompt shows pve-manager and the new packages, let it install, then reboot:

reboot

After the reboot, before migrating anything back, check that the node is healthy and that the new kernel is actually the one running:

uname -r
pveversion

If uname -r still shows the old kernel, the node booted the wrong entry and you have a boot-order problem to fix before you trust it. When everything checks out, verify the node rejoined the cluster and is healthy, migrate the workloads back, and only then move on to the next node. Always keep a majority of nodes online so you retain quorum and can migrate workloads off whichever node you upgrade next.

Conclusion

A 9.3 release is just another point release in disguise if you