From PVE 5 to 9: What Happens When Legacy Infrastructure Refuses to Let Go

# From PVE 5 to 9: What Happens When Legacy Infrastructure Refuses to Let Go There's a particular kind of stress that only shows up when you inherit someone else's infrastructure. Not the clean, well-documented kind. Not the "we'll migrate this next quarter" kind. I'm talking about the deeply lived-in, mission-critical, slightly dusty stack that's been humming along for years because one person knew exactly how it worked - and now they're not around anymore. That's the situation with a small business still running on **Proxmox VE 5.4-15**. A version that feels less like software and more like a time capsule. And now it needs to jump - not one version ahead - but all the way to 9. ## When "It Still Works" Isn't Enough On paper, the setup wasn't massive. Two nodes. A handful of VMs. A NAS for backups. Nothing exotic. One node had already been limping along on 8.x before its drives started failing. That got replaced with a new Supermicro micro server. Clean install. Fresh Proxmox 9. Things were actually... smooth. Backups via **Proxmox Backup Server** were working. Migration off the dying node went well. So far, so good. But then there's the old PVE 5 box. That machine is where the real ghosts live. ## The NAS That Chokes Backing up the remaining mission-critical VMs should be simple. In theory. In practice? Sending backups from PVE 5 to the NAS nearly cripples it. The NAS is a TerraMaster box in RAID 5 with a single 1Gb NIC. It's not running the VMs themselves - just acting as a mounted backup target. But when a backup job kicks off, everything slows to a crawl. The NAS bogs down. The network groans. It feels like you're pushing it one job closer to retirement. And here's the tension: the NAS is already on the upgrade list. But it's not here yet. So what do you do when the act of protecting your data might be the thing that breaks your storage? The community's response was refreshingly pragmatic: slow it down. Rate limiting isn't flashy. It doesn't feel like a "big solution." But setting `bwlimit` in `/etc/vzdump.conf` to cap transfer speeds - say 50MB/s - can be enough to stop the NAS from drowning under write pressure. Same idea on the PBS side using traffic control rules. It's not glamorous. It's not modern. But it works. And sometimes, the right answer isn't faster hardware. It's restraint. ## The Temptation to Skip Steps There's always that thought in the back of your mind: What if we just upgrade in place? 5 to 6. 6 to 7. 7 to 8. 8 to 9. Slow, methodical, supported paths. Except this isn't a lab. This is a business. And the VMs in question run ancient custom software that nobody quite knows how to rebuild from scratch. One of them is Windows 7. No internet access. Core service. Untouchable in the most terrifying way. The others are Windows 10, lightly connected but still critical. If those break, there isn't a reinstall script waiting in a Git repo. There isn't documentation. There's just anxiety. And that's what makes this jump from 5 to 9 feel less like an upgrade and more like open-heart surgery. ## The i440FX Warning That Won't Go Away After migrating some VMs to the Proxmox 9 node, a new warning appears: > Machine type 'pc-i440fx-5.1' is deprecated. > Current machine version is subject to deletion. It's not an error. Everything boots. But it's a ticking clock. The old i440FX machine type emulates a legacy PCI-based chipset. Modern Proxmox prefers Q35, which emulates a PCIe-based platform. On paper, that sounds minor - just virtual hardware under the hood. In reality? It's a platform swap. Switching from i440FX to Q35 isn't just flipping a dropdown. It can trigger device reinitialization. New virtual NICs. New PCI topology. Windows might see entirely new hardware. Which means: * Possible new IP addresses * Driver shuffles * Activation hiccups * That awful "Installing device driver software..." pause On a lab VM, fine. On a Windows 7 box running core business software that nobody wants to touch? That's a white-knuckle reboot. The advice from seasoned admins was blunt: treat it like new hardware. Plan for device re-detection. Expect to reconfigure networking. Don't assume it'll be invisible. But also - don't panic. In most cases, it works. It just requires deliberate handling. ## The Quiet Rule: Don't Cluster Across Generations One piece of advice stood out clearly: Don't cluster 5.x with 8.x or 9.x. The API differences alone can cause headaches. It's not worth it. If you're still on 5, don't try to build a hybrid Frankenstein cluster. Instead? Nuke and pave. Build fresh. Restore backups. Upgrade virtual hardware after landing in a modern release. Then upgrade guest tools. That clean break is often less risky than incremental patching through half a decade of changes. ## The "Just Copy the Disk" Argument There's always someone who suggests it - and they're not wrong. If the VM disk is a qcow2 file? `rsync` it. If it's LVM? `dd` and `ncat`. Power it down. Copy it. Recreate config from `/etc/pve/`. Technically sound. Emotionally terrifying. Because copying a disk image feels like bypassing the "official" path. It feels like duct tape, even when it's not. But here's the thing: Proxmox VMs are mostly just disk files and configuration text. There's no magic database hidden somewhere. If you understand what you're copying, it's perfectly valid. The key is downtime. The VM must be offline. No half-measures. And in many migrations, that direct disk copy is faster and less punishing on fragile storage than repeated backup cycles. ## There's Also the Veeam Route For Windows VMs, another option came up: treat them like physical machines. Tools like **Veeam Backup & Replication** can back up a Windows VM at the OS level and restore it into a new environment. It abstracts away the hypervisor jump. That's attractive when the hypervisor version gap feels dangerous. But again, it introduces another layer. Another tool. Another dependency. Sometimes simpler really is safer. ## The Emotional Weight of Legacy Systems There's a detail in this story that matters more than any bandwidth limit or machine type flag: This environment belonged to someone who cared deeply about keeping it running. And now someone else is carrying that responsibility forward. That changes how you approach risk. You don't want to be the person who "modernized" everything into downtime. You don't want to break the one Windows 7 VM that runs an ancient custom app no one understands. So you move carefully. You test backups repeatedly. You verify PBS jobs. You ask the community before touching machine types. You respect the system, even if it's outdated. ## What Actually Happens When Legacy Refuses to Let Go Here's the truth: legacy infrastructure doesn't fail all at once. It degrades in layers. First it's the drives. Then the warnings. Then the unsupported versions. Then the backup bottlenecks. Each layer whispers the same thing: "You should've upgraded earlier." But small businesses don't always have upgrade budgets. Or spare hardware. Or downtime windows. So environments like this survive longer than they should. And when the upgrade finally comes, it's a leap across years. The good news? Proxmox is surprisingly resilient across generations. With proper backups, offline disk copies, and careful hardware transitions, jumping from 5 to 9 is doable. The risky part isn't the software. It's the unknown custom workload inside those Windows VMs. ## The Playbook That Emerges If you strip this down to essentials, the strategy looks like this: 1. Ensure verified backups via Proxmox Backup Server. 2. Rate limit backups to avoid crushing old NAS hardware. 3. Avoid clustering mixed major versions. 4. Restore onto fresh 8.x/9.x nodes. 5. Upgrade virtual hardware deliberately. 6. Test before touching machine types. 7. Treat i440FX to Q35 as a platform migration, not a cosmetic change. Nothing revolutionary. Just disciplined execution. But that discipline is what keeps small businesses alive during transitions like this. ## And That Windows 7 Box? It's still there. Still running. Still isolated from the internet like a museum exhibit behind glass. Eventually, it'll need to move. Or retire. Or be virtualized inside another VM like some kind of digital nesting doll. But for now, it just needs to survive the hypervisor jump. And honestly? That's enough. Because sometimes modernization isn't about chasing the newest release. It's about carrying forward what already works - carefully, respectfully, and without breaking the things that keep the lights on.