Should you upgrade to Proxmox VE 9 yet? (and the Ceph—​Squid order of operations)

Draft cornerstone post — GTM experiment #1 (see docs/gtm-plan.md §3). Not yet published. Intended for a project blog + cross-post to r/Proxmox and r/selfhosted. Every time-sensitive fact below is the same curated, cited judgment CADENCE ships in its feed (feed-sample/proxmox-ve, feed-sample/ceph) — the post is that judgment, told as prose. Re-verify the dates against the linked sources before publishing; upgrade windows move.

It’s the question every Proxmox admin eventually types into a search bar, usually late at night with a maintenance window open: should I actually upgrade this cluster to PVE 9 — and if so, in what order? The release notes tell you what changed. They don’t tell you whether you, specifically, should move yet, and what will bite you when you do. That’s the gap this post fills.

Short version: PVE 9 is solid and you should plan the move — but not blindly, and almost certainly not Proxmox-first if you run Ceph. Here’s the judgment.

1. The clock is the first reason to care

PVE 9 is built on Debian 13 ("Trixie"), and the 9.x line is the supported one. The reason this isn’t a "whenever" decision is the other end: PVE 8 reaches end of support around the end of August 2026. Once it does, you’re running an unpatched hypervisor under everything else in your estate — the worst possible thing to be casual about.

So the real framing isn’t "should I upgrade?" It’s "I have a finite, shrinking window to upgrade on my own schedule before I’m forced to on someone else’s." Plan it now; execute it deliberately.

🔎 Sources to check before you act: the Proxmox VE 9.0 release notes and the Proxmox upgrade-from-8-to-9 guide.

2. If you run Ceph, the order of operations is the whole ballgame

This is the single most important thing in this post, and the thing the generic "is an update available?" tooling will never tell you:

Get Ceph onto Squid (v19) before you upgrade Proxmox to 9. Not after. Not at the same time.

PVE 9 expects a current Ceph, and the supported path is to bring the storage layer up first, while you’re still on a known-good hypervisor, then move Proxmox. Doing it in the wrong order — or discovering mid-upgrade that your Ceph release isn’t supported on the new PVE — is how a routine maintenance window becomes an incident.

There’s a second-order trap here, and it’s a good example of why "just get current" is not the same as "get current thoughtfully":

  • Ceph Reef (18) is already end-of-life (final backport was ~early 2026). If you’re on Reef, you are not in a safe resting place.

  • Ceph Squid (19) is the version PVE 9 wants — but Squid itself has a support horizon (its own EOL lands in late September 2026, with Tentacle (20) as the successor line).

So the honest advice is layered: get to Squid to unblock PVE 9 — but go in knowing Squid is a stepping stone toward Tentacle, not a five-year home. That two-move plan is exactly the kind of thing a checklist of "latest versions" can’t express and a human who’s done the upgrade can.

🔎 Sources: the Ceph releases page and the Proxmox Ceph documentation for your release.

3. The gotchas that actually cause the 2am pages

Assuming the order is right, these are the PVE 8→9 specifics worth rehearsing on a test node first:

  1. Run pve8to9 --full and read every line. It’s the official preflight and it’s good. Treat any warning as a task, not a suggestion.

  2. Plan for a NIC interface rename. The newer kernel can rename network interfaces, and if your bridge config references the old name, the node can come back up with no network. Have out-of-band/console access ready before you reboot — don’t upgrade a remote node blind.

  3. You’re rebooting into a new kernel (6.14 line). Expect it, schedule it, and verify your storage and networking come back before moving to the next node.

  4. PCI passthrough setups need extra care. If you pass through GPUs/NICs/HBAs, re-verify IOMMU groups and driver binding after the upgrade — passthrough is the most fragile thing across a major kernel jump.

None of these are reasons not to upgrade. They’re reasons to upgrade one node at a time, with a console open, after a dry run — which is the difference between a clean migration and a war story.

4. A decision checklist

Move to PVE 9 when all of these are true:

  • Your Ceph cluster is on Squid (19) (or you don’t run Ceph at all).

  • pve8to9 --full is clean (or every warning has a resolution).

  • You have out-of-band/console access to each node (for the NIC-rename risk).

  • You’ve done the upgrade on one node and watched storage + networking recover.

  • You know your PCI-passthrough config will survive the kernel jump (if applicable).

Hold (for now) if: you’re on Ceph Reef and haven’t scheduled the Squid move yet, or you can’t get console access to a node you’d be upgrading remotely. Don’t wait past the PVE 8 end-of-support window — that’s trading a planned window for an unplanned one.

5. Why this is hard to keep track of — and what we built

Notice what made the call above useful: it wasn’t the version numbers. It was the conditional, cross-product, time-aware judgment — Ceph before Proxmox; Squid unblocks you but is itself a stepping stone; the clock on PVE 8; the specific gotchas for your config. That judgment is real work to assemble, it goes stale, and it’s different for the estate that runs Ceph than for the one that doesn’t.

That’s the thing we’re building. CADENCE is a curated, signed upgrade-advisory feed for self-hosted stacks: a human (hi) maintains the judgment — install / hold / wait-for-patch / blocked / EOL, with conditions like "blocked until Ceph ≥ Squid" — and a small, source-available appliance you host pulls the signed feed, checks it against your local inventory (your inventory never leaves your network), and tells you the verdict for your cluster. It even shows you what changed in the advice since the last pull, and flags it if a safety verdict was ever softened.

It covers Proxmox/Ceph, Nextcloud, PostgreSQL, GitLab, Traefik, and Docker Engine today, and it’s the free package that makes a post like this unnecessary to write by hand every quarter.

  • Try the free Community feed + the source-available appliance: (GitHub link — pending launch)

  • Want it for the stacks you manage for clients? We’re taking a handful of MSP design partners.

(This post is curated judgment current as of mid-2026; CADENCE’s job is to keep it current so you don’t have to. Always confirm against the linked upstream sources before a production upgrade.)