Post-Upgrade Tasks

After the host reboots into Proxmox VE 9.x, complete the following before returning it to service.

Verify the upgrade

Confirm the host now reports Proxmox VE 9.2.3 or later:

pveversion

Re-run the checklist and confirm there are no remaining problems:

pve8to9

Note

After the upgrade, pve8to9 will still report a couple of expected items that do not indicate a problem on NDG hosts:

  • An intel-microcode (or amd64-microcode) FAILURE/WARNING — NDG hosts rely on BIOS-delivered CPU microcode, so the OS microcode package is intentionally not installed. Safe to ignore.

  • An INFO note that RRD files are “using the old format” — these only hold pre-upgrade historic graphs; Proxmox VE 9 records new metrics in a new format. Delete them to reclaim space or leave them.

In the Proxmox web UI, empty your browser cache / force-reload (CTRL + SHIFT + R, or ⌘ + Option + R on macOS) so the updated interface loads correctly.

Re-run the NDG PVE Post Install Script

The NDG PVE Post Install Script (v0.9 or later) detects Proxmox VE 9 and reapplies the correct repositories and NDG configuration (custom CPU models, datacenter tags, and so on).

From the host shell, run:

bash -c "$(curl -fsSL https://ndg.tech/pve-post-install)"

See the NDG PVE Post Install Script page for details on what it does.

Verify network interface names

The Proxmox VE 9.x kernel can occasionally rename a network interface (for example, ens4f0np0 could change), because interface names are derived from the hardware’s PCI(e) addressing. NETLAB+ networking is wired to specific interface names, so a rename would leave a bridge or VLAN pointing at a name that no longer exists. This is uncommon on typical NDG server hardware, but always verify it after each node upgrade.

Run the NDG network interface check:

ndg-pve-netcheck

The NDG PVE Post Install Script installs this tool and runs it automatically, so it is already present after the previous step. It confirms that every interface referenced in /etc/network/interfaces is present and that the host bridges (for example your management bridge, CLUSTER_NET, and NLCONTROL) are up.

Note

  • If all is well, it reports all referenced interfaces are present and host bridges are up — nothing more to do.

  • If a NIC was renamed, it lists the present NICs (with MAC address and the kernel’s alternate names) and offers to pin the correct NIC back to the expected name using pve-network-interface-pinning, then prompts you to reboot. It changes nothing unless you confirm.

Verify NETLAB+ connectivity

  • In NETLAB+, confirm the Proxmox datacenter/host reconnects and reports healthy.

  • Confirm SSH between the NETLAB+ VM and the host is working — NETLAB+ manages host networking over SSH.

  • Start a test pod to confirm cloning and networking behave normally.

Clusters

Repeat the entire procedure on the next node, starting from Prerequisites & Preparation. Upgrade and verify one node at a time until all nodes report Proxmox VE 9.2.3 or later.

NETLAB+-specific notes

Proxmox VE 9 changes and how they affect NETLAB+

Topic

Note

Network interface naming

The most impactful item for NETLAB+ — verify after every node upgrade (see above).

High Availability (HA)

The NDG Post Install Script disables HA, so the PVE 9 HA-groups-to-HA-rules change does not apply.

Containers (cgroup v1)

Proxmox VE 9 removes legacy cgroup v1. NETLAB+ uses virtual machines, not LXC containers, so this does not apply.

LVM autoactivation

On PVE 9, new logical volumes default to autoactivation disabled. The pve8to9 checklist flags any action needed.

High memory reported

Proxmox may report high VM memory usage due to ballooning/accounting; this is normal. See the Release Notes.