Just like typical distros, virtualization platforms receive major updates every so often to add new features, bug fixes, and security patches to your home lab. Proxmox received its last major release in August last year, with the update moving the underlying virtual environment to Debian 13 and the Linux kernel to 6.14. While the new additions are just as neat, the sad news is that the old Proxmox 8.x versions will hit their end-of-life stage later this August.

As such, you’ll have to upgrade to PVE 9.0 sooner or later, or risk running your home lab without any security patches. Credit where it’s due, Proxmox has neatly laid out the instructions for upgrading your nodes in the official documentation. That said, this process can involve way too many steps, and you’ll want to set aside extra time to troubleshoot random issues that may rear their ugly heads once you’ve upgraded to the latest version of the virtualization platform.

You’ll want to back up everything before jumping to Proxmox 9.0

Including the host settings

Updating your everyday machine has a slight possibility of breaking things, and the same applies on the home lab front. Except, you’ll have to be extra cautious, as you might end up with broken network services and irrecoverable virtual guests if things go south during the upgrade procedure. As such, it’s a good idea to back up every aspect of your Proxmox server to an external node (or even a cloud platform, if you don’t have the storage provisions locally).

I recommend going with a bare-metal Proxmox Backup Server rig, as it not only keeps your LXCs and VMs safe, but its reliance on incremental snapshots along with its data compression and deduplication features prevent the backup files from hogging too much disk space. Alternatively, you can create vzdump backups locally, provided you use an FTP app to transfer them to a separate machine, as you don’t want these files to go down if anything happens to your Proxmox hub during the transition from PVE 8.x to 9.0.

But aside from the virtual guests, I’d also recommend backing up the base Proxmox instance. You can either do this manually by saving the contents of /etc/pve/user.cfg, /etc/pve/storage.cfg, /etc/network/interfaces, and a bunch of other config directories, or rely on genius developer tis24dev’s ProxSave repo to handle the backup tasks for you.

The upgrade process involves simple steps

Or you can just yell YOLO and wipe everything clean

If you’re on Proxmox 8, you’ll first have to upgrade your node to version 8.4.9. Once that’s done, you’ll have to manually modify the Proxmox update repository to include Proxmox 9 packages. Otherwise, they won’t show up in the Updates tab, even if you’ve already got the community repository enabled. The fastest way to do so involves running the cat command to append the Debian 13 package links to the proxmox.sources config file:

cat > /etc/apt/sources.list.d/proxmox.sources Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Once that’s done, you should see the PVE packages within the Updates section, and pressing the Upgrade button will cause Proxmox to start the migration process. The virtualization platform will occasionally halt the process to ask for confirmation about specific settings, so you can’t just leave the terminal alone. I mostly went with default options for two Proxmox nodes when I updated them last year, and didn’t have many issues (aside from one massive problem on the first workstation that I’ll mention in a bit). Alternatively, if you’re not willing to put up with random compatibility issues, you could just go for a fresh installation and restore the virtual guests (and Proxmox config files) once the PVE setup wizard has worked its magic.

You might encounter a handful of issues

Especially if you’ve overprovisioned the local-lvm pool as I did

This section is precisely the reason why I keep stressing the importance of backups throughout the article. Although the update process can take anywhere between 30 minutes and an hour (or perhaps two, if you’ve installed PVE on a hard drive), a successful upgrade could still result in issues. Take the problem I encountered, for instance.

Since I work with dozens of LXCs and VMs, my goofy self accidentally overprovisioned the local-lvm pool on the main workstation. In actuality, my virtual guests consumed around 60% of the drive space, but their virtual disks were almost twice as big as the local-lvm pool. When I booted into the freshly-configured Proxmox 9.0 environment, I was greeted by an inoperable pool and broken containers and virtual machines. A glance at the logs revealed the activating LV 'pve/data' failed: Check of pool pve/data failed (status:64). Manual repair required! (500) error message, and I considered recovering my original setup just so I could bring my essential LXCs online.

Fortunately, some helpful folks at the Proxmox forums mentioned the lvconvert --repair pve/data command, and running it brought my local-lvm pool (and by extension, the virtual guests residing in it) back online. But that’s not the only error you could encounter during this process. I’ve heard about folks running into frame buffer freezes on Nvidia GPUs, and the fixes range from adding nomodeset as a parameter during the Proxmox boot menu to disabling Nvidia drivers in the /etc/modprobe.d/blacklist.conf file. In most cases, the Proxmox forums should have a solution to your upgrade maladies, and if nothing else works, wiping everything clean (and restoring the LXCs and VMs afterward) is always an option.