Published 1 minute ago
Ayush Pande is a PC hardware and gaming writer. When he’s not working on a new article, you can find him with his head stuck inside a PC or tinkering with a server operating system. Besides computing, his interests include spending hours in long RPGs, yelling at his friends in co-op games, and practicing guitar.
Having built my first server node using a nearly decade-old PC, the versatile nature of home labs is one of the main reasons why I love tinkering with virtualization and containerization tools. While there are certain home lab distros that need cutting-edge hardware, the DIY ecosystem has just as many tools designed to run on even the most ancient devices. Take Proxmox, for example. Besides powering my …
Published 1 minute ago
Ayush Pande is a PC hardware and gaming writer. When he’s not working on a new article, you can find him with his head stuck inside a PC or tinkering with a server operating system. Besides computing, his interests include spending hours in long RPGs, yelling at his friends in co-op games, and practicing guitar.
Having built my first server node using a nearly decade-old PC, the versatile nature of home labs is one of the main reasons why I love tinkering with virtualization and containerization tools. While there are certain home lab distros that need cutting-edge hardware, the DIY ecosystem has just as many tools designed to run on even the most ancient devices. Take Proxmox, for example. Besides powering my Xeon workstation, it works just as well on my mini-PCs, Intel N100 systems, and even old laptops.
Heck, I recently armed some old laptops with Proxmox to put them to good use instead of letting them gather dust in my cupboard. And with the right tweaks, both double as solid experimentation nodes for my home lab projects.
Related
Switching to LXCs for most tasks
And starting VMs when I absolutely need them
Native support for LXCs is one of the most impressive features of Proxmox. Rather than deploying a separate virtual machine just to run containers, PVE gets rid of the VM overhead by letting me run LXCs directly on the host machine – and it’s especially useful for laptops. Virtual machines isolate every aspect of the guest OS, while containers share the underlying kernel with the host machine. This makes LXCs less taxing on the hardware, and even though they have weaker isolation provisions than their VM counterparts, they’re more efficient for self-hosting useful services.
Take my Lenovo G510 from 2014, for example. When I tried running a single GUI-based Debian VM, the 2-core processor and 4GB memory couldn’t handle the distro. LXCs, however, are a different story, and even the weakest system in my arsenal was able to hold its own against 10+ LXCs. Meanwhile, my gaming laptop can handle a couple of virtual machines, provided I don’t go too far with overprovisioning resources and stick to LXCs for the majority of my experiments.
Storing the virtual guests on ZFS-powered drives
Let me preface this section by adding that ZFS is only applicable to systems with a decent amount of RAM, as the king of NAS-centric file systems is a massive memory hog – to the point where it can even siphon resources that are necessary for virtual guests. But having read the horror stories about silent corruption, I try to arm all my home lab nodes with ZFS whenever possible. Proxmox tends to use XFS for typical LVMs, but the platform also lets me create ZFS pools. Although ZFS’ powerful RAID provisions are useless for my former gaming behemoth and its limited drive capacity, it’s still a neat addition to my Proxmox setup.
After all, ZFS ships with the Copy-on-Write facility to ensure my virtual guest data remains safe even when a write operation fails, while its self-healing provisions provide extra reliability to my aged server node. The only caveat is that I had to add an extra 16GB of memory to my gaming laptop, but this was back in the good ol’ days before the RAM apocalypse made the memory prices go bonkers.
Making full use of the GPUs
Certain services can benefit from the integrated graphics
Both my laptops feature integrated graphics, but for the sake of being realistic, I’ll focus on my old gaming system and its Intel Graphics and GTX 1060 combo. While the graphics card is far from ideal for modern gaming, it can add extra features to some self-hosted apps. For example, Karakeep and Immich can leverage it for certain machine-learning tasks, and the same holds true for Paperless-GPT. Meanwhile, the Intel Graphics included with the i7-7700HQ processor can transcode multiple 1080p streams on Jellyfin.
Plus, I’ve already got the GPUs, so I might as well use them to their full extent. Passing the graphics cards to LXCs is a lot easier than with typical virtual machines, especially since I can let multiple containers use them without dealing with SR-IOV madness. However, letting a single virtual machine access a GPU at a time is also a viable option, with tools like PECU making this process a cakewalk.
Enabling console blanking
I don’t need the console screen open 24/7 on my laptop
Although Proxmox’s console interface is a godsend for troubleshooting critical issues, running it all the time on my laptops’ displays wastes a lot of battery life. I’m pretty accustomed to headless setups on my server nodes anyway, so I don’t need the IPv4 address or the console screen visible when I’m already working with the web UI.
Fortunately, Proxmox lets me turn the console blank during normal operation, though doing so involves navigating through certain config files. Inside the */etc/default/grub *document, I had to add the consoleblank=150 parameter within GRUB_CMDLINE_LINUX_DEFAULT. After a restart, the console screen would go away in 2.5 minutes. I could outright disable it, but the 2.5-minute duration is quite useful if (or rather, when) my portable PVE nodes encounter major issues that can only be solved via terminal commands.
Limiting the battery threshold to 80%
The built-in battery is not a UPS
Upon first glance, it’s easy to think of a laptop’s battery as a free UPS, as you get some extra minutes of server uptime during a blackout. Unfortunately, the closest analogy I can come up with for a laptop’s battery when it comes to 24/7 usage is a fire hazard. That’s because keeping a laptop plugged in even when the battery is at 100% can stress it out and cause it to swell over time.
A simple solution involves unmounting the battery and forgetting it even exists – which is precisely what I’ve done with my decade-old laptop. However, my gaming laptop requires a lot of effort to remove the battery, so I had to limit its charging threshold below 100%. First, I installed the TLP utility on the host system via the apt install tlp -y command. Then, I used the nano editor to access the */etc/tlp.conf *file and modified the START_CHARGE_THRESH_BAT0 parameter to =15 and the STOP_CHARGE_THRESH_BAT0 value to =80. This solution is far from ideal, but it’s a decent alternative to keeping the battery plugged in at 100% during my server experiments.
But I wouldn’t recommend leaving the lid closed when running Proxmox
For folks tempted to keep Proxmox running even while the laptop’s lid is closed, let me add that it’s far from a good idea. Many laptops have a cooling system that relies on the lid being open during normal operation. Keeping it closed while running demanding projects on Proxmox will cause the laptop to overheat, and you might end up with a damaged keyboard and screen in the long run.
Related
I clustered budget-friendly devices into a Proxmox HA lab, and it’s more useful than I thought
Clusters may not be for everyone, but they work really when you need high-availability support for your Proxmox nodes