Migrating from VMware to Proxmox for a quieter, cheaper homelab

The last Broadcom licensing shuffle turned a stable line item into a quarterly puzzle, and plenty of Australian sysadmins felt the squeeze first. A home server used to be a sunk cost, but a per-CPU subscription model turns the same rack into an ongoing accounting exercise, especially when the boss at work is asking why the lab kit costs more than a coffee subscription in Fitzroy. Proxmox VE has been on my radar for years, and the price shock was the nudge I needed. Learn more about 自作pcでケースファンの回転数をグラフィックカードの温度に連動させる制御方法.

This write-up walks through the migration I ran on my own kit: a beige box in the study, a NAS under the desk, and a few Raspberry Pi nodes for the boring jobs. It is the honest account of one engineer pulling the pin on VMware and rebuilding the same workloads on Proxmox, with the Australian context — power bills, the NBN, and the local IT market — folded in.

Why Proxmox makes sense in an Australian homelab

The headline reason is money, but the second-order reasons are what keep the migration interesting. A perpetual Proxmox subscription sits at a level most Australians would round to the cost of a servo refill. Proxmox is a Debian-based KVM hypervisor with a web UI that does not feel like a hostage video, and it ships with ZFS, Ceph, and Linux bridge networking out of the box. For someone running a few Windows VMs, a Linux jump host, and a couple of test containers, that covers the wishlist.

The other reason is locality. The default Proxmox ISO pulls updates from a German mirror, which is a long way from a Perth or Brisbane living room. Pointing apt at a closer mirror — AARNet caches or the standard au mirrors — keeps update windows short, and stops the lab sitting idle through a 300 MB patch download on a congested NBN link. The AWS Sydney region (ap-southeast-2) is reachable on a round-trip a homelabber can actually measure, which makes hybrid experiments feel less theoretical.

Planning the migration from VMware

The first afternoon is dull but pays for itself. Draw the current topology on a whiteboard, or in my case the back of a Coles receipt. List every VM, its OS, its vCPU and RAM allocation, the virtual switch it sits on, and the datastore it lives on. For each VM, also note whether it uses any VMware-specific tooling: VMware Tools, vSAN, NSX segments, or the snapshot scheduler. Proxmox handles a lot of that transparently, but proprietary guest tools and the vSphere APIs that PowerCLI scripts depend on are the things that will bite on cutover night.

Hardware planning matters more at home than at work, because the homelab is constrained. A Threadripper with 64 GB of RAM will run Proxmox happily; an old Dell Optiplex with spinning disks and 16 GB of RAM will technically work, but the experience will be grim. I budgeted for a RAM upgrade alongside the cutover, timed with the ATO financial year end so the line item could be argued as a business expense. Local retailers like MSY, Scorptec, and PCCaseGear ship fast within Australia, and the price difference on a 32 GB DDR4 kit is small enough that waiting three weeks on an imported part is not worth it.

The mechanics of the cutover

The actual move is two commands and a wait. Export each VM from VMware as an OVF or OVA, then use qm importovf or the web UI's import wizard to bring it into Proxmox. Storage targets can be local ZFS or a NAS directory, and networking maps cleanly: a vSwitch becomes a Linux bridge and a port group becomes a VLAN tag. The only manual step that caught me out was re-installing the guest agent — qemu-guest-agent on Linux, the VirtIO drivers on Windows — because VMware Tools and the QEMU agent are not interchangeable, and time drift sneaks in within an hour of booting without it.

For anyone worried about operational risk, the cutover can be staged: stand up Proxmox on a second drive or a second small box, migrate one or two non-critical VMs first, and only decommission the VMware install once the new stack has been running clean for a fortnight. Across the twelve VMs in my lab, the longest single reboot was the Windows domain controller, which had to sit through Windows Update and a driver pull over the NBN.

Tuning Proxmox for a real workload

A fresh Proxmox install is fine out of the box, but a tuned one is much nicer to live with. PCIe passthrough for a GPU or an HBA card requires vfio modules, an iommu line in GRUB, and a few lines in /etc/modprobe.d/. The short version is that any modern AMD or Intel CPU from the last six years handles it without drama. For storage, ZFS with a mirrored vdev for VM disks and a separate pool for bulk media gives both safety and speed, and ARC tuning is gentle enough to leave alone on a 32 GB box.

Cooling is where the homelab gets personal. A small tower under a desk in a Brisbane summer is going to scream, and the default fan curves on most motherboards are tuned for gaming, not 24/7 workloads. I ended up scripting a custom curve that ties case fans to the GPU temperature rather than the CPU, because the GPU is the slow-cooker in my setup. For anyone who cares about acoustics, the deep dive at GPU-tied fan curve control is worth a read.

Living with Proxmox day to day

Backups in Proxmox are built in, and the PBS (Proxmox Backup Server) appliance is free to run. A small VM on the NAS, doing nightly PBS jobs to a ZFS dataset, replaced a patchwork of cron scripts and rsync that had been the homelab's previous safety net. Snapshot retention can be tuned per VM, and the dedup across the PBS store is good enough that a weekly full plus daily incrementals is a realistic default without filling the disk.

Updates are the other daily reality. Proxmox ships a no-subscription repo by default, and the enterprise repo is free to enable for personal use at home — the catch is that you have to register a free key. It is worth pointing apt at a closer mirror so an update run does not peg the NBN during business hours. Once the cluster is stable, scripting the configuration drift away becomes the next obsession, and my notes on using f to automate server configuration tasks 205867 cover a chunk of that work. Monitoring is handled by the built-in dashboard plus a small Grafana stack with a Telegram bot wired in, so I get a ping on the phone when a VM dies. That is more useful than it sounds when the homelab is hosting the home automation and the lights are not responding.

Practical pointers before the cutover

• Test the import with a non-critical VM first; a domain controller or a database server is not the right guinea pig.
• Re-image the Windows guests with the VirtIO drivers before the cutover, or carry the driver ISO on a USB stick for the first boot.
• Keep the old VMware install on a separate drive for at least a fortnight after cutover, so a rollback is one reboot away.
• Budget for a RAM upgrade in the same purchase order; the migration is the right moment to do it.
• Register a free Proxmox enterprise key if the homelab will run unattended, to access the stable enterprise repo.

If you are weighing the move, the cost case usually closes itself within a single billing cycle, and the rest is careful plumbing. I have left the VMware vSphere client in a drawer, more out of habit than need, and the lab is quieter, cheaper, and more pleasant to operate. The lab also ends up running personal projects that have nothing to do with infrastructure, and one of those write-ups lives at casino app hold and win 213410 on the blog. Have a look at the consulting page if you would like a hand planning a cluster of your own, or to talk through a cloud migration that uses Proxmox as the on-ramp.