I like Proxmox because it is reliably straightforward in the best possible way. It runs my VMs, LXCs, and test environments without making itself the center of attention.
However, since Proxmox is the foundation for everything running on top, updates deserve more careful attention than just a casual apt full-upgrade
Here’s my practical update routine for Proxmox VE nodes – because future me is exactly the kind of person who logs in late at night, looks at a perfectly healthy Proxmox node, and thinks: “Let’s just quickly update this.”
… it was not quick …
Routine Proxmox updates
For normal Proxmox updates, I use the Proxmox shell or SSH into the node.
First, check the current version:
pveversion -v
Then refresh the package index:
apt update
Check what would be upgraded:
apt list --upgradable
Then apply the update:
apt dist-upgrade
I do not use -y here as i want to see what APT is about to change before I continue.
Important: Do not use apt upgrade as the normal Proxmox update command!apt update is fine because it only refreshes the package list.
Proxmox updates can include kernel, QEMU, LXC, ZFS and Proxmox package dependency changes. apt dist-upgrade / apt full-upgrade handles those changes correctly, while apt upgrade may hold packages back or leave the system in a less clean update state.
Check if a reboot is needed
After package updates, especially kernel updates, I check which kernel is currently running:
uname -r
And compare installed Proxmox kernels:
dpkg -l | grep -E 'pve-kernel|proxmox-kernel' | grep -v headers
If a new kernel was installed, reboot the node when the workloads can handle it:
reboot
After the reboot:
pveversion -v
systemctl --failed
For a single-node homelab this is usually simple. For a cluster, update one node at a time.
Backups before bigger changes
Snapshots are useful, but snapshots are not backups.
Before a larger update or major upgrade, I want at least:
vzdump --all --mode snapshot --storage <backup-storage> --compress zstd
Or even better: use Proxmox Backup Server.
I also back up important host configuration:
mkdir -p /root/pre-upgrade-backup
tar czf /root/pre-upgrade-backup/pve-config-$(date +%Y%m%d).tar.gz \
/etc/pve \
/etc/network/interfaces \
/etc/hosts \
/etc/hostname \
/etc/resolv.conf \
/etc/apt/sources.list \
/etc/apt/sources.list.d
For ZFS or Ceph setups, I would also document the current state:
zpool status > /root/pre-upgrade-backup/zpool-status-$(date +%Y%m%d).txt
zfs list > /root/pre-upgrade-backup/zfs-list-$(date +%Y%m%d).txt
If Ceph is used:
ceph -s > /root/pre-upgrade-backup/ceph-status-$(date +%Y%m%d).txt
ceph osd tree > /root/pre-upgrade-backup/ceph-osd-tree-$(date +%Y%m%d).txt
This is not fancy. It is just the boring information you want when something behaves differently afterwards.
Guest snapshots
For quick rollback of individual guests, snapshots can be useful.
VM snapshot:
qm snapshot <vmid> before-update --description "Before Proxmox update"
LXC snapshot:
pct snapshot <ctid> before-update
Rollback example:
qm rollback <vmid> before-update
pct rollback <ctid> before-update
Major upgrade example: Proxmox VE 8 to 9
A major Proxmox upgrade is not just a normal package update. Proxmox VE 9 is based on Debian 13 Trixie and includes newer core components such as QEMU, LXC, ZFS and Ceph Squid.
Before starting, make sure the node is already on the latest Proxmox VE 8.4 packages:
apt update
apt dist-upgrade
reboot
Then check:
pveversion
Run the upgrade checker:
pve8to9 --full
Do not ignore failures. Fix them first!
For me, this is the point where I would also remove or disable third-party repositories. Docker repos, old monitoring repos, random helper script leftovers – everything that touches APT can make a Debian major upgrade more difficult than necessary.
Check your repositories:
cat /etc/apt/sources.list
ls -l /etc/apt/sources.list.d/
grep -R -E "bookworm|trixie|proxmox|enterprise|no-subscription" /etc/apt/sources.list /etc/apt/sources.list.d/
Do not blindly replace every bookworm with trixie in every file. That can break third-party repositories or leave you with mixed package sources.
For Proxmox VE 9, prefer proper deb822 .sources files instead of old .list files where applicable. The official Proxmox documentation uses the newer deb822 style for Trixie-based installations.
I would run this either directly on the console or inside screen or tmux!
apt install screen
screen -S pve-upgrade
Then run:
apt update
apt dist-upgrade
After the upgrade:
reboot
Then verify:
pveversion -v
uname -r
systemctl --failed
journalctl -p err -b
apt list --upgradable
Cluster update approach
For a Proxmox cluster, I update one node at a time.
My usual flow:
- Check cluster health.
- Migrate workloads away from the node.
- Put the node into maintenance if HA is used.
- Update or upgrade the node.
- Reboot.
- Verify that the node rejoins cleanly.
- Move to the next node.
Check cluster status:
pvecm status
pvecm nodes
corosync-quorumtool -s
For VMs:
qm migrate <vmid> <target-node> --online
For containers:
pct migrate <ctid> <target-node>
If HA is used, place the node into maintenance mode before working on it:
ha-manager crm-command node-maintenance enable <node>
After the node is back and healthy:
ha-manager crm-command node-maintenance disable <node>
Important: do not use this as a normal health check:
pvecm expected 1
That command changes quorum behavior. It can be useful in very specific recovery cases, but it is not a normal “verify cluster status” command. For normal checks, use:
pvecm status
corosync-quorumtool -s
Post-update checklist
After the update or upgrade, I check:
pveversion -v
uname -r
systemctl --failed
journalctl -p err -b
apt list --upgradable
qm list
pct list
pvesm status
For clusters:
pvecm status
pvecm nodes
corosync-quorumtool -s
My verdict
Updating Proxmox is not difficult, but it deserves a calm process.
For normal updates, the process is usually simple: check the system, refresh the package list, review what will be upgraded, and use apt dist-upgrade or apt full-upgrade. The important part is to avoid blindly running commands without knowing what will change.
For major upgrades, I slow down. I want proper backups, exported configuration files, clean repositories, the official upgrade checker, and enough time to fix something if it does not go as planned.