Use a migration gate before upgrading to Proxmox VE 9

Do not approve an upgrade to Proxmox VE 9 until every node has a tested restore route, verified out-of-band console access, healthy visible storage, stable cluster networking, a clean repository plan and a documented response to a failed kernel boot. The move from Proxmox VE 8 to the current 9.x series spans a Debian major-version transition and changes across the kernel, virtualisation and storage stack, so it needs to be managed as a migration gate rather than an unusually long package update.

That sounds obvious, yet Proxmox VE upgrades are often treated as an unusually long package update. Proxmox VE 9 moves the platform from the Debian 12 era to Debian 13, with substantial changes underneath the familiar web interface. The original 9.0 release brought a newer kernel, QEMU, LXC, ZFS and Ceph stack; the current 9.2 release, announced on 21 May 2026, takes that further with Linux kernel 7.0, QEMU 11.0, LXC 7.0 and ZFS 2.4. An upgrade undertaken now is normally an 8.x-to-current-9.x transition, not a narrowly bounded move to the initial 9.0 codebase. (proxmox.com)

Treat it as a migration gate. No single warning guarantees trouble, but every unresolved dependency needs an owner, a recovery route and a reason for accepting the risk. The bundled pve8to9 --full checker is essential input. It isn’t the whole process.

Prerequisites: establish a real go/no-go baseline

Bring every node to the latest available Proxmox VE 8 packages supported by the official upgrade path, then run the checker on every node, not just the least unusual one. Proxmox’s 8-to-9 guidance expects an up-to-date 8.4 baseline, and the checker surfaces conditions ranging from old guest machine types and legacy containers to bootloader, repository and LVM concerns. (datahunter.org)

Save the output. A green summary is not much use once the maintenance window has moved on. Record:

• pveversion -v and uname -a from each node;
• pve8to9 --full output, including warnings judged acceptable;
• Current repository files, package holds, locally installed packages and DKMS module status;
• Cluster status, node addresses, Corosync links, storage definitions and HA configuration;
• Copies of /etc/network/interfaces, relevant firewall rules, /etc/hosts, boot parameters and any local scripts that mount storage or alter networking.

This isn’t paperwork for its own sake. It gives the person on call something better than memory when a NIC names itself differently, a third-party driver fails to build, or a custom LVM setting matters during the upgrade.

Stage 1: prove the recovery path before touching the host

A backup that has never been restored is an assertion, not a recovery plan. Take current VM and container backups to storage independent of the node being upgraded, then restore a representative workload. Pick something awkward: a Windows guest with application-consistent backup requirements, a container with bind mounts, or a VM with several disks and a non-default VLAN. Confirm that it boots, its data is present and the service works.

Proxmox VE supports archive backups and Proxmox Backup Server; the latter provides deduplication, incremental transfer for running VMs and live restore. Useful features, certainly. They don’t remove the need to test the restore path, credentials, backup datastore access and guest usability. (pve.proxmox.com)

Back up platform configuration separately. Guest backup data won’t necessarily reconstruct networking, storage definitions, firewall configuration, subscriptions, local hooks or the manual change made two years ago and since forgotten. For a cluster, preserve a controlled copy of the relevant cluster configuration and node-local files. Don’t casually copy files back into a live /etc/pve without understanding quorum.

Then test the access route that doesn’t depend on Proxmox networking: iKVM, IPMI, iDRAC, iLO, serial console or physical console. Test it properly. Can the on-call engineer authenticate, see the firmware boot menu and select a previous kernel? SSH over the bridge being changed is not a recovery channel.

Kernel rollback is useful, but it isn’t a full rollback

Upgrade plans often blur an important distinction. A kernel rollback can recover a host whose new kernel or boot entry fails. It does not safely reverse a completed Debian major-version upgrade, package removals, database/schema changes or changed configuration semantics.

Before the migration window, document the boot arrangement with commands such as proxmox-boot-tool status where applicable, efibootmgr -v, findmnt /boot /boot/efi, lsblk -f and cat /proc/cmdline. Confirm whether the host uses GRUB, the Proxmox boot tool, UEFI or legacy boot, and where its EFI system partitions sit. Don’t infer this from the storage filesystem alone.

For UEFI systems with an LVM root filesystem, Proxmox has documented a GRUB issue where the appropriate EFI GRUB package must be present; the issue does not apply to root-on-ZFS or legacy boot in the same way. The 8-to-9 checker also flags the obsolete systemd-boot meta-package because it can interfere with boot-related package upgrades. Treat both as migration blockers until the documented remediation is complete and verified. (forum.proxmox.com)

The proper platform rollback plan is usually less glamorous: restore guests onto a known-good host, rebuild the affected node from the appropriate installation media and documented configuration, or revert a validated infrastructure snapshot where one exists. That is closer to reality than “just boot the old kernel”.

Stage 2: make storage boring before upgrading anything

That flexibility makes version planning more important: decide which Ceph release the cluster should run, follow the supported Ceph upgrade sequence, and don't overlap a host-platform migration with an unhealthy storage cluster.

Storage is where a smooth-looking node upgrade becomes an outage. Confirm that every configured storage is online from every node expected to use it, guest disks are where the configuration says they are, and free capacity covers migrations, backups, snapshots and recovery work. Run pvesm status; inspect ZFS pools with zpool status; review multipath and iSCSI sessions where those are in use; and resolve degraded Ceph health rather than hoping it remains merely inconvenient.

Hyper-converged Ceph deserves its own gate. Proxmox VE 9 initially shipped with Ceph Squid 19.2, while current 9.2 also supports the newer Ceph Tentacle line. That flexibility makes version planning more important: decide which Ceph release the cluster should run, follow the supported Ceph upgrade sequence, and don’t overlap a host-platform migration with an unhealthy storage cluster. (proxmox.com)

Proxmox VE 9’s support for snapshots on thick-provisioned shared LVM storage is a welcome addition for iSCSI and Fibre Channel environments. It isn’t a reason to rush the upgrade. Check vendor multipathing guidance, SAN firmware support, path failover behaviour and the actual snapshot/backup policy first. A feature announcement doesn’t validate the interaction between your array, HBA firmware, multipath configuration and workload. (proxmox.com)

Pay close attention to LVM warnings. In VE 9, newly created LVM and LVM-thin guest logical volumes are created with autoactivation disabled. Existing upgraded volumes are not automatically converted, but the change matters where shared LVM, recovery scripts or non-standard activation behaviour are involved. Review any local lvm.conf overrides rather than blindly accepting a checker suggestion. (forum.proxmox.com)

For organisations using external SAN storage, this is also the time to check whether array snapshots, replication and backup workflows are producing recoverable copies rather than merely successful job logs. Our review of the HPE MSA 2062 makes the wider point: affordable shared storage can be capable, but its operational value rests on sensible capacity margins and tested recovery, not the badge on the front.

Stage 3: freeze network design and validate what survives a reboot

Don’t redesign bridges, VLANs, bonds and firewall policy in the same window as a major operating-system upgrade. If networking needs improvement, make it a separate, reversible change with its own test plan. Combining the work creates the familiar post-reboot problem: nobody knows whether the failure is a new kernel driver, an interface rename, an LACP mismatch, a VLAN trunk omission or a typo in /etc/network/interfaces.

Proxmox uses the Linux network stack and stores node networking configuration in /etc/network/interfaces. Its documentation recommends the GUI and ifupdown2 workflow because configuration is staged before application; it also warns against casual use of old ifup/ifdown habits, which can interrupt guest traffic. (pve.proxmox.com)

Validate the following in the live environment before the upgrade:

• Each physical NIC maps to the expected switch port and MAC address;
• Bond mode agrees with switch configuration; use LACP only where the switching estate is actually configured for it;
• VLAN-aware bridges have the required tagged VLANs permitted end to end, including management and migration networks;
• The management IP, default route, DNS and node name resolution are consistent on every node;
• Corosync has resilient connectivity and is not competing with backup or storage traffic on a saturated link;
• Firewall rules permit the management, cluster, migration and storage flows required during a rolling upgrade.

Proxmox specifically recommends multiple Corosync networks for redundancy and notes that congested storage or backup traffic can push cluster latency high enough to create serious HA consequences. A rolling upgrade is the wrong time to discover that the cluster network is really one busy bond. (pve.proxmox.com)

Where hosts rely on custom systemd link files or pinned interface names, verify them against the real NIC MAC addresses. A major kernel and userspace transition isn’t guaranteed to break interface naming, but “not guaranteed” is not a migration control.

Stage 4: inventory guests, integrations and awkward exceptions

Move or stop workloads on the node being upgraded, and choose the order deliberately. Start with a node that is representative but not uniquely critical. If it has PCI passthrough, unusual storage, proprietary monitoring agents or a third-party kernel module, it isn’t the first node unless it is the only realistic test case and time has been allowed for recovery.

Legacy containers are a clear blocker. Proxmox VE 9 no longer supports the legacy cgroup v1 environment, so containers depending on very old systemd releases, including common examples such as CentOS 7 and Ubuntu 16.04, need to be replaced, rebuilt or kept on an appropriate supported platform while a migration is completed. (homelab.casaursus.net)

Review VM machine types, CPU models and guest agents. Test live migration of a non-production VM if cluster CPUs differ, particularly across generations or vendors. Review virtual TPM use, UEFI guests, GPU and NIC passthrough, nested virtualisation, and application licensing tied to virtual hardware. Failures here are not always Proxmox defects; more often, they are assumptions made years ago and never revisited.

Inventory automation too. Terraform providers, Ansible roles, monitoring scripts, API users and custom roles can encode privileges or endpoints that change. For example, Proxmox staff have advised that custom roles using the removed VM.Monitor privilege need adjustment after the VE 9 upgrade, with replacement privileges depending on the intended operation. Small integration details like this can leave an otherwise successful migration looking broken to operations teams. (forum.proxmox.com)

Disable or update third-party repositories before switching from Debian Bookworm to Trixie. APT sources for monitoring agents, GPU drivers, storage utilities, security tooling and container runtimes must have a compatible Debian 13 release or be removed for the migration. DKMS modules are a specific risk because the new Proxmox kernel may expose a build failure only after packages are unpacked. Don’t solve that with a forced upgrade and optimism.

For a broader platform-selection discussion, see our Proxmox, VMware, Hyper-V and HPE Morpheus value comparison. Once the choice is made, migration discipline matters more than another comparison table.

Stage 5: run the rolling upgrade as a controlled change

1. Confirm quorum and HA state. Don’t take a node down if doing so leaves the cluster unable to make safe decisions. Disable or relocate HA workloads deliberately; accidental failover is not a maintenance method.
2. Evacuate the node. Live-migrate compatible guests or shut down services within the agreed outage window. Check local disks, passthrough devices and anti-affinity rules before assuming a guest can move.
3. Run the checker again. Resolve failures. For warnings, record the rationale and corrective action. A warning about running guests, a stale name resolution entry or a bootloader package is not background noise.
4. Perform the official repository and package procedure. Follow Proxmox’s current 8-to-9 guide exactly for the chosen subscription repository model. Review package-manager prompts rather than blindly retaining locally modified files or automatically replacing them.
5. Run the checker after package upgrade and before reboot. This is the last useful chance to detect a boot-related or configuration issue while the old running environment remains accessible.
6. Reboot from out-of-band console. Watch the first boot. Verify the selected kernel, storage imports, network interfaces, cluster services and management connectivity before moving on.

Verification: what must work before the next node moves

Don’t call a node upgraded because the web UI loads. Verify that it is in quorum, reports healthy storage, sees the expected bridges and VLANs, and reaches peer nodes over the intended networks. Confirm backups can still run, then carry out a small restore or at least a controlled backup validation on the first upgraded node.

Start one representative VM and one representative container. Check guest agent status where used, attached disks, application traffic across the relevant VLANs, and monitoring and alerting. Test a migration between an upgraded node and an unupgraded node only where the official mixed-version upgrade guidance permits it and the guest’s CPU model supports it. Don’t use a production database as the compatibility probe.

For each node, capture the new package and kernel state, preserve the upgrade log, and record deviations. Then proceed. Moving a little more slowly is generally cheaper than restoring confidence after an avoidable second-node failure.

When to pause or roll back

Pause immediately if any of these are true:

• The restore test has not completed successfully;
• Out-of-band access is unavailable or untested;
• Ceph, ZFS, SAN paths or shared storage are degraded;
• The cluster lacks quorum margin or Corosync is showing instability;
• The checker reports bootloader, repository, LVM or name-resolution failures that are not understood;
• A required third-party package or DKMS driver has no compatible Debian 13 path;
• Legacy cgroup v1 containers or essential custom roles have no migration plan.

After an upgrade, roll back operationally rather than theatrically. If the new kernel won’t boot, use the documented boot recovery route and previous known-good kernel where appropriate. If the platform is unstable, stop rolling forward, protect the remaining nodes and recover services from tested backup or onto a known-good host. Trying to reverse a completed major APT upgrade under pressure is usually the worst of both worlds.

Proxmox VE 9 has useful storage, networking and platform improvements. None changes the central operational fact: the safest upgrade is the one that can be stopped cleanly. Build that gate first. The package work is the easy part.