Over the last couple of years, I’ve installed Proxmox on PCs of all shapes and sizes, including enterprise-grade servers, dinosaur machines, single-board computers, and gaming laptops. After all, Proxmox’s lightweight nature lets me run this killer platform on anything with an x86 CPU, and since it supports Linux containers and KVM-based virtual machines, I can use my PVE-powered systems as hybrid project-building workstations and self-hosting hubs.

But no matter what version I use, Proxmox’s default settings are far from ideal – to the point where I’d often modify them as soon as I’m done installing the virtualization platform on a new guinea pig device.

By default, Proxmox uses its enterprise repo for updates

It’s impossible to get updates without enabling the no-subscription repo

Although most PVE enthusiasts are aware of the enterprise repo, I’ve often seen newcomers leave their Proxmox update settings at the default values and wonder why the platform doesn’t receive new packages or security patches. You see, Proxmox sets its enterprise repository for updates upon a fresh installation, and unless you’ve bought a subscription, your Proxmox node will throw errors if you try updating it.

Fortunately, Proxmox has the no-subscription repository, which includes almost every tool you need to turn your PVE node into a powerful server. I used to enable it manually by heading to the Updates section of the Datacenter tab back in the day, though I’ve started executing the Post Install script from the community-driven Proxmox VE-Helper Scripts package. Besides taking care of the repository issue, it also gets rid of the subscription nag and disables certain cluster services – once I give it the approval, that is. And unless I’ve got plans to use a node in a cluster, I almost always let it turn them off…

Disabling certain cluster settings reduces the SSD strain

I also enable Log2Ram on old SSDs

Let me be clear: as much as I love HDDs, I configure Proxmox installations on SSDs, partly because my bulky hard drives can’t fit inside half the mini-PCs in my arsenal, and also because I’ve got spare SSDs recycled from outdated machines. But reliability is a bit of an issue with salvaged drives, especially for SSDs with limited write cycles. Worse still, pve-ha-lrm.service and pve-ha-crm.service tend to write data frequently on the Proxmox boot device. Now, I verify the drive health on my SSDs before I send them through the PVE grinder and only use cheap drives for test systems, not on my main workstation.

Disabling these cluster services not only prevents extra SSD wear on my standalone nodes, but it also slightly decreases the resources they’d otherwise siphon when writing to my boot drives. Since I’m a worrywart, I’ve also configured Log2Ram on cheaper Proxmox systems I’ve cobbled together from old components. True to its name, this handy tool writes logs to the system memory for the most part, and only saves them on the SSD at infrequent intervals, thereby reducing the write operations just a tad more.

I always configure a Pulse agent on fresh PVE nodes

Pulse is the best home lab monitoring utility by a long shot

Proxmox undoubtedly has a neat web UI for managing containers and VMs, but it’s not the best for quickly checking the health and resource consumption metrics of my virtual guests. Fortunately, genius developer rcourtman designed Pulse, a powerful monitoring service that works exceedingly well with Proxmox. Besides automatically discovering my LXCs and VMs, it can pull all their essential statistics, and even supports remote monitoring for multiple PVE nodes.

And that’s where the aforementioned Pulse agent comes into the picture. I’ve got a centralized Pulse instance on a secondary node that I’ve armed with all the documentation and networking tools (so I don’t bring it down with my home lab experiments), and the agents section within Pulse’s Settings generates a fresh command that I can execute on fresh PVE instances to add them to my monitoring server.

Proxmox’s default power settings are somewhat unoptimized

I often fiddle with the BIOS settings on power-hungry systems

I’ve mostly got old hardware powering my home lab, so you’d expect the energy consumption rate to be off the charts. But with the right set of optimizations, it’s possible to tone down the energy-guzzling tendencies of Proxmox rigs quite a bit. I tweak the scaling governor on every new PVE node, as this setting is responsible for setting the CPU’s clock speeds during different tasks – including idle workloads. Specifically, I set the scaling governor to powersave instead of the default performance profile, which aggressively throttles down the processor frequency when it’s not actively in use.

Since my Proxmox machines aren’t involved in tasks requiring high CPU horsepower (at least, not unless I specifically use them to host remote gaming VMs) and tend to remain idle most of the time, powersave is the perfect option for my setup. I’ve also enabled C-States, Eco Mode, and ASPM (and disabled boost clocks) in the BIOS of most PVE nodes, just to save some extra watts every month.

A couple more tweaks for Proxmox enthusiasts

Proxmox’s solid first-party companion tools are yet another reason I adore its ecosystem, and I always pair fresh PVE nodes with its Datacenter Manager utility. Besides providing a neat UI comprising all the systems in my home lab, it lets me migrate LXCs and VMs seamlessly between nodes, even if they’re not clustered together. I’ve also connected several PVE rigs with my local Proxmox Backup Server instances, though I’ve started clamping down on my snapshot automations after I nearly choked a PBS-powered mini-PC with unnecessary virtual guest files.

Meanwhile, if you’re looking for some tips to improve your VM performance, I’d recommend setting the CPU option to host. While you shouldn’t use it on cluster nodes bearing different CPU types, the host setting can improve your VM’s responsiveness. Likewise, switching the Display option to SPICE gets rid of the cursor lag and overall sluggishness on GUI-laden VMs, and I wish I’d known about this setting during my early Proxmox days.