Proxmox VE 9 in homelab: practical checklist before the upgrade

Proxmox VE 9 is a major release: Debian 13 base, newer kernel, QEMU 10, LXC 6, Ceph Squid, and OpenZFS 2.3. It is not the classic "click and hope" update. In a serious homelab, or in a small corporate infrastructure where Proxmox hosts real services, it must be treated as scheduled maintenance: inventory, verified backups, downtime window, and a rollback plan.

The good news is that the upgrade is manageable. The bad news is that many homelab installations grow by stratification: bridges created years ago, NFS storage mounted "on the fly", critical VMs without documentation, LXC containers with local bind mounts, cluster nodes with mixed versions. Proxmox VE 9 brings interesting improvements, but precisely for this reason, it is best to approach it in an orderly manner.

Why evaluate Proxmox VE 9

The most useful new features for a SysAdmin are not just "newer versions". Debian 13 brings a more modern and supportable base, QEMU 10 improves the virtualization part, LXC 6 updates the container world, ZFS 2.3 introduces important evolutions, and Ceph Squid is the reference for those using storage clusters. In the Proxmox roadmap, there are also interesting works on snapshots as volume chains, designed to extend similar semantics to storage that historically was less flexible compared to ZFS.

In practice: Proxmox VE 9 is interesting if you want to stay on an updated platform, prepare for upcoming features, and reduce technical debt. It is not mandatory to update it on the first day on nodes hosting critical services that are working fine.

First rule: verified backup, not "backup present"

Before touching the node, actually verify your backups. If you use Proxmox Backup Server, check at least:

• last successful backup for each VM and container;
• verification jobs completed without errors;
• free space on the datastore;
• retention consistent with acceptable risk;
• ability to restore to alternative storage.

A quick shell check on the node can help:

pvesm status
vzdump --dumpdir /tmp --mode snapshot --compress zstd <VMID>

There is no need to do a manual backup of everything if PBS is healthy, but for the most critical VMs it makes sense to run an on-demand backup before maintenance. Even better: try at least a partial restore or a file restore from PBS. An untested backup is a hope, not a procedure.

Minimum node inventory

Before the upgrade, save the current state. A few commands are enough, but they must end up outside the node: in your documentation repository, in a vault, or at least on another server.

pveversion -v
pvecm status
qm list
pct list
pvesm status
ip -br addr
ip route
cat /etc/network/interfaces

If you use ZFS:

zpool status
zfs list
zpool get all | grep -E 'ashift|autotrim|fragmentation'

If you use Ceph:

ceph -s
ceph osd tree
ceph versions

This inventory serves two purposes. First: to understand what you are upgrading. Second: to have a reference if after the reboot a VM does not start, a storage does not mount, or a bridge does not behave as before.

Pay attention to networking and storage

The worst troubles in Proxmox upgrades are often not in the GUI, but in networking and storage. Check Linux bridges, bonds, VLANs, and MTU. If you have special configurations, avoid "cleaning up" network files during the same upgrade window. Change one thing at a time.

For storage, verify NFS/CIFS mounts, iSCSI targets, multipath, and local datastores. If you have VMs with disks on remote storage, the availability of that storage during the reboot is crucial. If you use Directory storage on external disks or manual mounts, make sure they are in /etc/fstab or managed predictably.

ZFS deserves a separate note: Proxmox VE 9 includes OpenZFS 2.3.x, with important new features such as RAIDZ expansion by adding devices. It is an interesting feature, but do not mix it with the platform upgrade. First upgrade and stabilize. Only afterwards evaluate structural changes to the pools.

Cluster: no rush and quorum under control

On a Proxmox cluster, upgrade one node at a time. First drain the node with live migrations where possible, or cleanly shut down VMs less suitable for migration. Check quorum and cluster status:

pvecm status
ha-manager status

If you use HA, avoid improvised maintenance: put services in a manageable state, document which resources can move and which cannot, and verify that shared storage is actually shared. Mixed versions between nodes are tolerable during an upgrade window, not as a permanent state.

Recommended sequence

A reasonable procedure for homelabs and small IT environments is this:

1. read the Proxmox VE 9 release notes and the roadmap page;
2. fully update Proxmox VE 8 to the latest available minor;
3. verify backup and restore;
4. export inventory of networking, storage, VMs, and containers;
5. plan the window and communicate downtime;
6. upgrade a non-critical or less loaded node;
7. reboot and verify VMs/containers;
8. wait a few days before upgrading the most important nodes.

Do not also upgrade firmware, network schema, ZFS layout, and Proxmox version in the same night. It is efficient only until something breaks; then it becomes impossible to understand the cause.

Post-upgrade checklist

After the reboot, do not just look at the green dashboard. Check:

• pveversion -v to confirm the packages;
• cluster status and quorum;
• available storage in pvesm status;
• automatic startup of critical VMs;
• VNC/SPICE console;
• internal and external networking of VMs;
• nightly backup jobs;
• system logs with journalctl -p warning..alert -b.

For a homelab, I would also add a very concrete test: turn off and on a non-critical VM, do a migration if you have a cluster, run a manual backup to PBS, and try a file restore. If these four tests pass, you have much more information than a simple "running" screen.

Realistic rollback plan

Rolling back a hypervisor is not trivial. This is why the plan must be realistic: VM backups, saved configurations, and the ability to reinstall the node if necessary. In small environments, the cleanest rollback is often not "package downgrade", but reinstalling the previous version and restoring configurations/VMs.

If the node is standalone, consider having an installation USB ready, IPMI access or physical console, PBS credentials, and network documentation. If it is a cluster, make sure you can move workloads to the other nodes before intervening.

Conclusion

Proxmox VE 9 is a release to follow closely, especially for those using Proxmox as an advanced lab base or small production. The point is not to be afraid of the upgrade: it is to avoid the random approach. Verified backups, inventory, network and storage checks, gradual upgrade, and post-reboot tests are the difference between orderly maintenance and a night lost in front of the console.

My advice: prepare the checklist now, upgrade a secondary node first, and do not mix the upgrade with other infrastructure changes. In a well-managed homelab, operational discipline counts as much as the hardware.

Main sources: Proxmox VE 9 release notes, Proxmox VE roadmap, Proxmox Backup Server documentation, and Proxmox Backup Server 4.x notes.