标签：#proxmox

A Windows 11 VM in Proxmox VE was showing nearly 100% memory usage in monitoring. Inside Windows Task Manager, however, actual memory usage was only around 30–50% . At first glance, that looks like a monitoring problem. It wasn't. The issue was in the VM configuration: the PVE Ballooning Device had been disabled , which meant Proxmox VE was not receiving the guest memory statistics needed to reflect the actual Windows memory state. I encountered this while monitoring a Proxmox VE environment with OpsHome NOC. This post documents how I traced the discrepancy and fixed it. The symptom On the same Proxmox VE host, the memory usage of Ubuntu VMs looked normal. One Windows 11 VM was different. The VM had 24 GB of RAM configured, but the monitoring result remained close to: Memory: 100% Used: about 24.2 GB Total: 24 GB Inside Windows 11 Task Manager, however, the VM was clearly not using all of its memory. The difference looked roughly like this: Monitoring: 90%–100% Windows 11: 30%–50% That is too large a difference to treat as a normal sampling variation. If you encounter something similar, especially when Linux VMs on the same Proxmox host look normal, do not immediately assume: Windows has a memory leak The monitoring threshold is wrong The monitoring application is calculating memory incorrectly The more important question is: Is Proxmox VE actually receiving the correct memory statistics from the Windows guest? Checking BalloonService inside Windows 11 For Proxmox VE to obtain useful guest memory statistics from a Windows VM, the VirtIO Balloon driver and its related Windows service need to be available. Inside Windows 11, I opened PowerShell and checked BalloonService: Get-Service * balloon * The result showed: Running BalloonService So the Windows-side BalloonService was already installed and running. At this point, the guest-side service did not appear to be the problem. The next step was to check the VM configuration on the Proxmox side. Checking the Proxmox VE

tailscale up --tun=userspace-networking gets you a green dot in the admin console and almost nothing else. The node appears in your tailnet, tailscale status looks healthy, and then you try to SSH into that container from your laptop and the connection hangs until TCP gives up. Two lines in the LXC config file fix it, and the container stays unprivileged. That's the whole post, really. But those two lines only make sense once you understand why every guide pushes you toward userspace mode in the first place, and what you're giving up by staying there. Who should care Anyone running services in unprivileged LXC containers on Proxmox who wants those containers to be real tailnet members with their own 100.64.0.0/10 address. Not reachable through something else. Reachable directly, over WireGuard, with a kernel network interface that ip addr can see. If you're already routing everything through a subnet router, you have a working setup and this is an optional upgrade. I covered that pattern in Tailscale Subnet Routers . Treat this as the next rung on the ladder: instead of one node advertising routes on behalf of everyone else, each container carries its own identity, its own ACL surface, and its own direct path to peers. What userspace networking actually costs you Every LXC-and-Tailscale guide I've read lands on the same instruction: pass --tun=userspace-networking and move on. It works because it sidesteps the problem entirely. Rather than asking the kernel for a TUN device, tailscaled runs a userspace TCP/IP stack (gVisor's netstack) inside its own process and never opens /dev/net/tun . Those costs stay invisible until you trip over one. Outbound traffic needs a proxy. In userspace mode, tailscaled exposes SOCKS5 and HTTP proxies on a local port. Nothing on the system routes to 100.64.0.0/10 automatically, because there is no interface and no route. Every client has to be told about the proxy: # userspace mode: this is the only way out export ALL_PROXY = socks5://l

Back in February I published a post about osx-proxmox-next , a tool that builds a macOS VM on Proxmox with one command instead of an afternoon of OpenCore plist editing. About 1,500 people read it. Some of them installed it. On hardware I don't own. That's when the interesting bugs showed up. 150 commits later, here are five failures that don't appear in any macOS-on-Proxmox guide I've found, with the actual root cause for each. 1. The installer stalls at 100% CPU and nothing moves Symptom: macOS installer reaches the copy phase. CPU pegged at 100%. Disk IO and network throughput both flat zero. It sits there forever. Only on Xeon E5/E7 v2-v4 hosts. My first fix was wrong. The stall looked like a network problem, so I assumed the vmxnet3 kext was failing to load during install and swapped those hosts to e1000-82545em . Shipped it. Then issue #103 came back from someone with the actual hardware: vmxnet3 got network fine, and e1000-82545em did not attach at all. I had made it worse. The real cause is two layers down. Those chips are genuine HEDT parts with dual-socket / multi-die topology, and -cpu host leaks that topology straight through to the guest. Pair it with a MacPro7,1 SMBIOS, which macOS treats as multi-socket capable, and XNU's scheduler livelocks under heavy multithreaded IO. The installer copy phase is exactly that workload. The fix is to stop passing the host topology through: _XEON_HEDT_PATTERN = re . compile ( r " Xeon.*E[57][ -]*\d+ *v([234]) " , re . IGNORECASE ) def _xeon_hedt_cpu_model ( model_name : str ) -> str : match = _XEON_HEDT_PATTERN . search ( model_name ) if not match : return "" if match . group ( 1 ) == " 2 " : return " Haswell-noTSX,model=158,stepping=3 " return " Broadwell-noTSX,model=158 " Lesson I keep relearning: the symptom showed up at the network layer, the cause lived in CPU topology. Guessing from the symptom cost me a release. 2. The VM boots into Recovery forever Symptom: Fresh install finishes. Every subsequent boot lands b

Most "why Proxmox" content in 2025-2026 is a migration story driven by Broadcom's ESXi pricing changes. The author had a working VMware stack and got priced out. I'm not that author. I evaluated both, picked Proxmox in 2024, and built on it without ever running ESXi in production. Two years in, I'd make the same call. It reads as either incompetent or contrarian until the rest of the post lands. Here's the reasoning. The three reasons it was the easy call 1. LXC and KVM in one host Most workloads in this homelab are LXCs. Pi-hole, Vaultwarden, Authelia, Traefik, the monitoring stack, GitLab CE itself, all containers sharing the host kernel. A few things need full VM isolation (the NAS guest, Proxmox Backup Server, the Home Assistant OS appliance). Same hypervisor, same CLI, same web UI for both shapes of workload. The alternative is ESXi for the VMs and a separate toolchain (containerd, Docker, Kubernetes, take your pick) for the containers. That's two backup pipelines, two HA stories, two places for config drift to surprise you at 2 AM. pct exec 254 systemctl status authelia and qm start 189 are the same shape. New hires don't have to learn one tool for containers and a different one for VMs. 2. Proxmox Backup Server beats the free Veeam alternative Chunk-level deduplication. Backups across guests and across time share storage. A nightly backup of all 11 LXCs and 2 VMs runs in about ten minutes and adds a few hundred MB of new chunks, because most of the content is the same as yesterday. Cluster-scheduled. One job definition runs across every node in the cluster. No per-node cron, no manual rotation when a node moves. Restore to a different storage class. A backup taken from local-lvm on the G7 restores onto ZFS on a G5 cluster node without conversion gymnastics. Veeam Community Edition is the free comparison. It works. It also caps repository size, doesn't dedup at the chunk level, and lacks the cluster-aware scheduling that makes PBS feel like a built-in feature

A homelab box that never sleeps runs 8,760 hours a year. So the spec that decides what it costs you is not the one on the box. It is the one nobody prints: how many watts it pulls sitting at the login prompt doing nothing. I kept hitting this while shopping for a Proxmox node, so I put the measured numbers in one place. More on that at the end. First, why the spec sheet lies to you. TDP is a thermal budget, not a power reading TDP is the heat the cooler has to handle at full tilt. It is a design target for the heatsink, not a measurement of what the chip draws, and it says almost nothing about idle. Your homelab box spends 95%+ of its life idle, so the number that runs up the meter is idle wall power, and that number is never on the product page. The arithmetic is unforgiving. One watt running continuously is 8.76 kWh a year. So the gap between a 7 W box and a 35 W box is not 28 watts, it is about 245 kWh a year, every year, for as long as the box is on. Plug in your own rate to get the dollars; the point is the gap compounds. Where TDP actively misleads you A few measured results from the dataset I'll link below, all from third-party wall-meter readings, not vendor claims: The new N100 wave is genuinely low. A Minisforum UN100C measures 5 to 7 W at idle. Beelink, GMKtec and Trigkey N100 boxes land in the 6 to 10 W range. For a Pi-hole, a few containers and some light VMs, this tier is hard to beat on running cost. AMD mini PCs idle far higher than their marketing suggests. A Minisforum UM790 Pro measures 25 to 45 W at idle. A Beelink SER6 Pro lands at 20 to 35 W. These are fast little machines, but if you picked one expecting "small box, small draw," the meter disagrees, and over a year that delta is real money. Newer and higher-TDP is not lower-idle. A Dell OptiPlex 7060 Micro idles just over 18 W on its 65 W-TDP desktop chip. The older 7070 with a six-core part sits around 13 W, and the low-power "T" SKUs lower still. The CPU's TDP class predicted idle better tha

Having a server at home opens up a huge range of possibilities. I'd been thinking about setting one up for a while, and when I finally got started, I realised that half the process was simply deciding what to buy and what to install. So what is a home server actually good for? There are obvious advantages like cutting SaaS costs or gaining privacy, but there's one that matters more to me than all the others: learning . In this post I'll walk through the process, the options I considered and why I ended up building my server around a Beelink S12 Pro running Proxmox VE . Why a mini PC? The first decision is form factor. The most common options are: An old PC or laptop from the cupboard. It works, but it's usually noisy, consumes a lot of power and takes up too much space. A Raspberry Pi. Small and incredibly power-efficient, but limited in RAM and processing power for running several services at once. A NAS. A solid choice if storage is the main priority, but the price climbs quickly. A mini PC. Small, silent, low power consumption, reasonable price. Clear winner. The mini PCs I considered In 2025, there are three families that make sense for a home lab: Intel N95 / N100 is probably the most popular choice right now for this kind of use. Very good energy efficiency, full virtualisation support and highly competitive prices. The N100 is more efficient than the N95; the N95 wins slightly on raw performance but at the cost of a bit more power draw. There are countless manufacturers building models around these chips, and the difference between them is usually minimal: what varies is the connectivity, the stock RAM and the after-sales support. Mac Mini deserves a mention because it's one of the most well-known options on the market. Performance is excellent and power consumption is surprisingly low, but for me the problem is the price — clearly higher than a Chinese mini PC — and I don't need something like that to get started. Fanless mini PCs (no fan). Fully passive mod