Proxmox VE 9.1 to 9.2 Upgrade Checklist for Homelabs

A Proxmox VE 9.1 to 9.2 upgrade is usually a package update, not a reinstall, but a homelab can still trip over ZFS-on-root, a stale PBS backup, or a guest agent that stops reporting after a kernel change. This checklist walks through the pre-upgrade checks, the package upgrade, and the post-reboot tests that prove your VMs, containers, ZFS pools, and PBS backups are still healthy. The outcome is a boring upgrade: one reboot, all services green, and a verified restore point if something misbehaves.

Key Takeaways

• Check first: Confirm package candidate, ZFS pool health, PBS reachability, and running guests before touching the upgrade.
• Back up first: Take a manual PBS backup of critical guests and verify a restore, not just a green backup job.
• Upgrade one node: In a cluster, drain and upgrade one node at a time so a bad package does not take down the whole datacenter.
• Reboot deliberately: Kernel and ZFS module changes need a reboot; schedule it after the package upgrade finishes.
• Prove it works: After reboot, verify the PVE version, services, ZFS, PBS backups, and guest agents.

Is Your Homelab Ready for the 9.2 Upgrade?

Before you upgrade, get a baseline you can compare against later. On a single-node homelab, this takes about ten minutes. On a cluster, it takes longer because you need to know which node is quorate and which guests can move.

pveversion -v

The version output should show a 9.1 release. When the repository is ready, the candidate package should show 9.2.0.

apt-cache policy pve-manager

pve-manager:
  Installed: 9.1.4
  Candidate: 9.2.0

If the candidate is still a 9.1 version, stop and check the Proxmox repository configuration. A no-subscription homelab usually points at the no-subscription package repository for the Debian base release.

deb http://download.proxmox.com/debian/pve trixie pve-no-subscription

Now check the services that matter most. If something is already unhealthy, fix it first.

systemctl status pveproxy pvedaemon pve-cluster --no-pager

For clusters, confirm quorum and node state.

pvecm status

If the cluster is healthy, the online node count and quorum state should match what you expect. If you are about to take a node out for upgrade, this is also the moment to confirm that the remaining nodes can survive without it.

Finally, check disk space. A package upgrade is usually small, but ZFS logs, snapshots, and PBS temporary files can make a nearly full root filesystem unhappy.

df -h /

If your root filesystem is below 15 percent free, clean up logs, old ISO images, or snapshots before upgrading.

How to Protect VMs, ZFS, and PBS Before You Touch Packages

The upgrade itself rarely breaks a running guest, but the reboot can. The safest homelab pattern is to prove you can restore before you change the host.

Start with PBS storage reachability. First list the storage definitions on the node.

pvesh get /nodes/$(hostname)/storage --output-format json

Then check the backup storage status. Replace the storage ID in the next command if your PBS storage is not named pbs.

pvesh get /nodes/$(hostname)/storage/pbs/status --output-format json

Take a manual backup of the guests you care about. A full nightly backup is not enough if the last successful backup is three days old and you have made configuration changes since then.

vzdump 100 101 --storage pbs --mode snapshot --compress zstd

For a larger set of guests, you can back up everything at once, but be ready for a long pause.

vzdump --all --storage pbs --mode snapshot --compress zstd

On my homelab, a 12 GB incremental PBS backup of three critical virtual machines took about four minutes. That number is small, but it is the difference between a quick restore and a weekend rebuild.

If you have not tested a restore recently, start with the PBS restore test before adding another upgrade risk. A backup that has never been restored is just a hope with a nice web interface.

Next, check ZFS. The goal is not just to see a pool name; it is to confirm that no devices are offline, degraded, faulted, or waiting for a resilver.

zpool status -x
zpool list
zfs list

If the pool is not healthy, stop and run a ZFS pool health audit before upgrading. Upgrading a degraded pool can turn a manageable problem into a very bad afternoon.

If the pool is healthy, start a scrub so you know the pool was checked shortly before the upgrade.

zpool scrub rpool

Replace rpool with your pool name if it differs. You do not need to wait for the scrub to finish before upgrading, but you should know where it started.

For ZFS-on-root systems, a pre-upgrade snapshot is cheap insurance. If your root dataset is the common Proxmox ZFS root layout, take a snapshot before the package upgrade.

zfs snapshot rpool/ROOT/pve-1@pre_9_2_upgrade

This snapshot is not a full cluster rollback, but it can help if the new kernel or package set behaves badly and you need to compare dataset state.

How to Upgrade Proxmox VE 9.1 to 9.2 Without Breaking VMs

For a point release, the upgrade path is straightforward. The important discipline is to review the changes, let the package manager finish, and reboot at a controlled time.

Refresh the package index first.

apt update

Then simulate the upgrade so you can see whether the package manager wants to remove anything unexpected.

apt-get -s dist-upgrade

If the simulation only shows the expected Proxmox, QEMU, kernel, and library updates, proceed.

apt dist-upgrade -y

apt autoremove -y

During the package upgrade, running virtual machines usually stay up. The upgrade replaces host components, but it does not normally stop guests unless you reboot. The web interface may become briefly unavailable while services restart, so avoid making configuration changes during the upgrade.

If you are upgrading a cluster, do not upgrade every node at once. Move critical workloads off the node, upgrade one node, reboot it, verify it rejoins, then move to the next node.

qm migrate 101 pve2
pct migrate 201 pve2

Replace the guest IDs and target node with your own values. Some live migrations fail because of storage, CPU flags, or network assumptions. If a guest cannot live migrate, schedule a short shutdown instead of forcing it.

On a small homelab with a dozen guests, the package download and unpacking took about six minutes. The reboot and ZFS pool import added another two minutes. That is a reasonable window if you do it in the evening.

What Usually Goes Wrong During a 9.1 to 9.2 Upgrade

The most common problem is not that VMs disappear. It is that the host becomes less predictable after a reboot.

One experience-based gotcha: after one point upgrade, a Windows virtual machine was running and reachable on the network, but the Proxmox summary page no longer showed its IP address. The guest itself was fine. The QEMU Guest Agent needed attention, either because the agent service had not started cleanly or because the guest-side agent was older than expected. Check the guest agent before assuming the VM is broken.

qm agent 100

Another common issue is ZFS. If the host uses ZFS for root storage or VM storage, a kernel update can make the first boot after the upgrade feel slower than usual because the pool must import and datasets must mount. In most cases, patience is enough. If the pool imports and the services start, do not start poking at ZFS properties just because the boot log is noisy.

A third issue is PBS. If the backup storage is unreachable because of a firewall change, DNS issue, or PBS service restart, the upgrade may still finish, but your backup job will fail later. Test the storage connection after the reboot, not only before the upgrade.

The honest tradeoff is that a manual backup before every point release feels excessive for a throwaway test node. For a homelab with ZFS-on-root, PBS backups, and a few critical services, it is still the cheapest insurance available. The time spent restoring a failed upgrade usually dwarfs the time spent running a backup.

How to Verify ZFS, PBS, and VMs After the Reboot

Once the node is back, run a short verification pass. This is the part many people skip, and it is the part that saves you from discovering a problem during the next scheduled backup.

Confirm the installed version.

pveversion -v

pvesh get /version --output-format json

Check the core services.

systemctl status pveproxy pvedaemon pve-cluster --no-pager

For a cluster, confirm the node is online and quorum is healthy.

pvecm status

Check ZFS.

zpool status -x

The output should say the pool is healthy. If you started a scrub before the upgrade, decide whether to let it continue or check the result later.

List the guests and make sure they are running as expected.

qm list
pct list

If you use guest agents, test a few important guests.

qm agent 100
qm agent 102

For containers, you can check whether the container is running and reachable.

pct status 201

Then test PBS again.

pvesh get /nodes/$(hostname)/storage/pbs/status --output-format json

If the storage is healthy, take one more manual backup of a critical guest after the upgrade. This proves that the new host can still write to PBS.

vzdump 100 --storage pbs --mode snapshot --compress zstd

After the upgrade, compare your guest configuration against the Proxmox VE 9.2 VM checklist if you also want to verify post-install settings such as CPU type, memory ballooning, disk cache, and firewall state.

What to Do If the Upgrade Hitches

If a service fails to start, check the journal before rebooting again and again.

journalctl -xeu pve-cluster --no-pager
journalctl -xeu pveproxy --no-pager
journalctl -xeu pvedaemon --no-pager

If the package manager was interrupted, repair dependencies before doing anything dramatic.

dpkg --configure -a
apt-get -f install -y

If the kernel is not the version you expected, confirm what is running.

uname -r

If ZFS is involved, confirm that the ZFS module is available for the running kernel.

modinfo zfs

Do not remove kernel packages while testing a new Proxmox release. Keep the previous kernel as a fallback until you have confirmed that PBS backups, guest networking, and ZFS storage all behave normally.

For a single-node homelab, the practical rollback plan is usually a PBS restore of the affected guest or a full node reinstall from a known-good ISO and PBS restore. For a cluster, the plan is simpler: leave the bad node out, keep the cluster running on the remaining upgraded nodes, and fix the node offline.

Upgrade Path at a Glance

Step	Typical homelab time	Main risk
Pre-check	10 minutes	Wrong repository or unhealthy service
Manual PBS backup	5 to 30 minutes	Backup job fails silently
Package upgrade	5 to 15 minutes	Unexpected package removal
Reboot	2 to 5 minutes	ZFS pool or service startup delay
Restore test	15 to 60 minutes	Backup exists but cannot restore

The table is not a promise, but it is a useful planning window. If any row takes much longer than expected, stop and inspect before moving on.

Conclusion

A Proxmox VE 9.1 to 9.2 upgrade should be a short, controlled operation: check the host, back up critical guests, upgrade one node at a time, reboot, and verify ZFS, PBS, and guests. The real safety comes from the verification steps, not from the upgrade command itself. Your next step is to pick one non-critical node or guest, run through this checklist end to end, and then upgrade the rest of the homelab with confidence.