Steps for a successful Proxmox VE 9 upgrade

Proxmox VE 9 brings newer kernels, updated QEMU/KVM, and refreshed management components. That helps with newer guest OSes and features, but it also shifts hardware requirements a bit. On older boxes, I start with the upgrade path and check what needs attention first. Proxmox is still a rolling set of Debian packages, so this is a package-driven change, not a single installer. Expect kernel, storage, and network driver changes. Plan for a reboot and have fallbacks ready.

A Dell R720 is a common homelab rack server. It often runs older Broadcom NICs, PERC RAID controllers, and Intel Xeon CPUs. Those parts usually work, but drivers and firmware are the variables. My approach is hardware-first: check firmware, RAID driver support, and NIC drivers before attempting a Proxmox VE 9 upgrade. Do not assume everything will boot the same after a kernel bump.

Useful checks:

• lspci -nn to list controllers.
• dmesg | grep -i -E 'raid|error|firmware' to spot worries.
• uname -r and pveversion -v to record current state.

If a driver is missing after the upgrade, the server may boot but lose storage or networking. That can be fixed, but it is slower than having a tested snapshot or backup.

I have seen plenty of threads where people upgrade older servers without issue, and plenty where they regret rushing it. The same pattern keeps turning up: the ones with backups and a live boot test recovered quickly. The ones without spent hours digging through logs. Treat online reports as data points. Use them to shape your test plan, not as a binary answer on compatibility.

Do not wing this.

Steps I use:

1. Update firmware and BIOS on the Dell R720 to the latest vendor release you can get.
2. Record current state: uname -a, pveversion -v, lsblk, lspci -nn, ip a.
3. Put hosts in maintenance mode: shut down non-essential VMs and stop scheduled jobs.
4. Create a file-level copy of /etc/pve and /etc/network/interfaces (or your network config).

Commands:

• apt update && apt full-upgrade

• systemctl stop pve-cluster pvedaemon pveproxy (only if you plan node-only work)

If you want to test first, boot the Proxmox VE 9 installer ISO on a USB and run it in live/test mode where possible. That shows driver problems without changing the host.

Backups save time.

I use two patterns:

• Host-level config backup: tar czf /root/pve-config-YYYYMMDD.tgz /etc/pve /etc/network /root/.ssh
• VM backups: use vzdump or the GUI backup job. I prefer snapshot mode for LVM or ZFS, and stop mode for critical VMs if snapshotting is not available.

Example vzdump command:

1. vzdump 101 --mode snapshot --compress zstd --storage local-lvm
2. vzdump 102 --mode suspend --compress zstd --storage local

Keep at least two recent backups and validate one restore on a spare host or local VM. Store backups off the node if you can.

Firewall rules for Proxmox

Export and save firewall rules before changing packages. Proxmox stores cluster firewall rules under /etc/pve/firewall. I save them with:

• tar czf /root/pve-firewall-YYYYMMDD.tgz /etc/pve/firewall

In the GUI, Datacenter → Firewall → Options shows status. Node-level: select the node → Firewall → Options. Note which IPs and ports are open. If the upgrade replaces pveproxy or changes the network stack, firewall rules may come back differently. Keep console access or IPMI ready.

Step-by-step upgrade process

1. Verify backups and console access. Confirm pveversion -v and uname -a.
2. Set maintenance: migrate or stop VMs you can.
3. Update package lists: apt update.
4. Perform the host upgrade: apt full-upgrade.
5. Reboot into the new kernel.
6. Verify services and VMs. If all is well, clean old kernels and packages.

Typical commands:

1. apt update
2. apt full-upgrade -y
3. reboot

If you need to change repositories for a major release, do that only after reading the official Proxmox upgrade guide and replacing sources in /etc/apt/sources.list.d/* as directed.

GUI backup: Datacenter → Backup → Add. Choose storage, schedule, and mode (snapshot/suspend/stop). Click Start to run a one-off backup.

GUI upgrade checks: Datacenter → Node → Summary shows package information and kernel version before you reboot. After the upgrade:

• Click Node → Summary to check the kernel line.
• Datacenter → Summary to see cluster health.

CLI verification commands:

• pveversion -v
• systemctl status pvedaemon.service pve-cluster.service pveproxy.service
• journalctl -b -p err

Verification of successful upgrade

Expected outputs:

• pveversion -v should list pve-manager with a 9.x version string.
• systemctl status pvedaemon.service should show Active: active (running).
• dmesg | tail should not list critical driver errors.

Verify VMs start:

• qm start
• qm list shows running state.

If the kernel changed, check uname -r matches the expected new kernel.

If any step changes the node state, such as kernel or storage layout, note the rollback plan before reboot.

Post-upgrade checks to perform

Run through:

• pveversion -v
• systemctl status pve-cluster pvedaemon pveproxy
• lsblk and mount to confirm storage
• ip a and ping the default gateway
• zpool status if using ZFS
• ceph -s if using Ceph

Start a representative VM and test networking and storage IO.

Troubleshooting tips

1. Use IPMI or a physical console to avoid lockout.
2. Boot an older kernel from GRUB to regain access.
3. chroot from a rescue environment to repair files if the root filesystem is damaged.
4. Reinstall or enable missing kernel modules with apt and modprobe.
5. Check firmware versions; sometimes rolling back a kernel is faster than chasing a firmware-only fix.

Commands that help:

• dmesg | less
• journalctl -xe
• ip link set dev up
• lsmod | grep

Takeaways: test, back up, and keep console access. If hardware looks fragile after a kernel bump, stop and recover from backups rather than debug under production load.