Hypervisor Platform Uplift (Proxmox VE 8 → 9) #

Move both hypervisors from Proxmox VE 8.4 to the 9.x series. This is a prerequisite for the tenant fabric, not routine patching — PVE 9 is what makes the EVPN underlay manageable as code.

✓ 3 | ↻ 0 | ⏳ 2 (5 total)

Legend: ✅ Complete | 🔄 In Progress | ⏳ Planned

Project Vision & Scope #

Both hypervisors currently run PVE 8.4.1. PVE 9 is based on Debian 13 (Trixie), so this is a major-version distribution upgrade on each node, not a package update.

In Scope

dv02hyp002p02 (tenant hypervisor, node dv02hyp002p02) — upgrade to PVE 9.x
dv02hyp001p01 (management hypervisor, node dv02hyp001p01) — upgrade to PVE 9.x
Post-upgrade verification of the SDN API surface the tenant fabric depends on
Alignment of the Terraform provider baseline with the upgraded platform

Out of Scope

Building the tenant fabric itself — tracked in Tenant Platform
Clustering either hypervisor — both remain standalone per ADR-0001
Ongoing patch strategy — tracked in Patch Automation

Why this blocks the tenant fabric #

ADR-0001 build requirement #4 calls for a real underlay/VTEP identity now, defined as code alongside the rest of the fabric, so that adding a fabric member later is “add a neighbor” rather than “invent an underlay after the fact.”

PVE 9 introduced SDN Fabrics — routed underlays (OpenFabric / OSPF) defined as first-class SDN objects and driven through the API, expressly to serve as an EVPN underlay. PVE 8.4 has no such object: verified against dv02hyp002p02, GET /cluster/sdn/fabrics returns “Method not implemented”.

On 8.4 the underlay would have to be a hand-maintained loopback in /etc/network/interfaces plus a static peers list on the EVPN controller. That is precisely the node-local, hand-carried state that requirements #2 (SDN-as-code) and #4 (real underlay identity) exist to prevent.

Upgrading first means the underlay is Terraform-managed from line one. dv02hyp002p02 currently holds no tenant workloads, so this is the cheapest point in the project’s life to do it.

Pre-upgrade assessment ✅ #

Establish what each node needs before either is touched.

✅ Run pve8to9 --full on dv02hyp001p01 and dv02hyp002p02 and record the findings
✅ Confirm both nodes are on the latest 8.4 point release first (an upgrade prerequisite)
✅ Confirm root filesystem headroom (≥ 10 GB recommended) and a tested backup of every guest
✅ Confirm out-of-band access to each node before starting — the upgrade drops network mid-run
✅ Review breaking changes against the estate: cgroup v1 removal (old-systemd containers), /etc/sysctl.conf no longer honored (move to /etc/sysctl.d/), /tmp becomes tmpfs

Uplift dv02hyp002p02 — tenant hypervisor ✅ #

Do the tenant hypervisor first; it carries no tenant workloads yet, so the blast radius is smallest and it is the node the fabric work is waiting on.

Move repositories from Bookworm to Trixie and perform the distribution upgrade
Verify the node returns healthy, guests start, and storage is intact
Confirm GET /cluster/sdn/fabrics is now served

Uplift dv02hyp001p01 — management hypervisor ⏳ #

The management plane runs here, so this node carries real workloads and needs a maintenance window.

Inventory what runs on dv02hyp001p01 and what an outage affects before scheduling
Same upgrade path; verify the management plane comes back whole

Verify the fabric API surface ✅ #

Confirm the platform now supports what the tenant fabric design assumes.

SDN fabric objects (OpenFabric / OSPF) present and writable via the API
EVPN controller, zone, VNet, subnet, and IPAM endpoints behave as expected on a standalone node — the fabric is self-contained per hypervisor, not cluster-scoped
frr present on the tenant hypervisor; an EVPN zone will not come up without it

Align the provisioning toolchain ⏳ #

Re-baseline the bpg/proxmox Terraform provider pin against the upgraded platform. The provider’s supported target is PVE 9.x; on 8.x it documents that functionality may be limited and that 8.x issues will not be addressed.
Prefer the short-form proxmox_sdn_* resource names — the older proxmox_virtual_environment_sdn_* forms are deprecated and are removed at provider v1.0.

Status #

dv02hyp002p02 is upgraded and the gate is cleared. Verified against the node on 2026-08-30:

Check	Result
`GET /version`	`9.2.11` (release 9.2) — was 8.4.1
`GET /cluster/sdn/fabrics`	served (`fabric`, `node`, `all`) — was “Method not implemented”
`frr-pythontools`	`10.6.1-1+pve3` present
`libpve-network-perl`	`1.6.7`
SDN objects	clean slate — no fabrics, controllers, zones or vnets; default `pve` IPAM

The tenant fabric is no longer blocked, and its underlay is defined as code rather than as hand-maintained node state — which was the whole reason for the gate. Implementation is tracked in Tenant Platform.

dv02hyp001p01 remains on 8.4.1. It carries the management plane, so it needs its own maintenance window; nothing in the tenant fabric waits on it. Nor does tenant DNS ( ADR-0004) — cloning a template and running a container work fine on 8.4.1, and the PVE 9 features that matter (SDN, EVPN) live on dv02hyp002p02.

The PVE 9.2-1 installer ISO is published to the artifact server (isos/proxmox), so the uplift — or a full reinstall — can be done with no internet access. Its checksum is verified against Proxmox’s GPG-signed SHA256SUMS rather than a hash pasted into inventory.