DEV Community: LK Wood IV

Proxmox LXC or VM: a per-service table, a decision tree and the gotchas

LK Wood IV — Tue, 10 Nov 2026 03:56:23 +0000

Adapted from LXC vs VM in Proxmox: When to Use Each, published on TechFuelHQ.

The kernel decides it. A Proxmox VM boots its own kernel on virtual hardware. An LXC container, which Proxmox calls a CT and manages with pct (the Proxmox Container Toolkit), runs on the host's. So a container runs only Linux and can't live-migrate, while a VM runs Windows or FreeBSD as readily as Linux and can take a whole PCI device. The Proxmox behaviour below is from Proxmox VE 9.2 (released May 21, 2026) and its 9.2.12 manual, dated September 18, 2026.

Which one for each service

Service	Put it in	Why
Docker host (Compose stacks)	VM	Proxmox's container chapter keeps nesting application containers inside a QEMU VM as a recommended practice for maximum isolation and live migration. Docker in an unprivileged LXC runs with `nesting=1,keyctl=1`. I'd still put a Compose stack in a VM.
Home Assistant	VM running HAOS	Home Assistant calls HAOS the recommended installation type for most users. A container install has no apps, and Z-Wave is controlled by an app.
Plex or Jellyfin on an Intel iGPU	LXC	Pass `/dev/dri/renderD128` in as a device with the render group's GID. The driver stays on the host.
Plex or Jellyfin on a dedicated NVIDIA card	VM, when one guest gets the card	With PCI passthrough the VM owns the card, and the host and other VMs can't use it. Sharing it with an LXC instead needs the NVIDIA kernel driver on the host, since a container runs on the host's kernel.
NAS operating system (TrueNAS)	VM with the disk controller passed through	For data you care about, TrueNAS says the storage controller must be assigned to the VM via PCI passthrough. TrueNAS lists VM snapshots and live migration among what passthrough gives up; ZFS snapshots inside TrueNAS still work.
File shares from the host's own ZFS pool	LXC with a bind mount	The host keeps the pool and hands one directory to the container: `pct set 100 -mp0 /mnt/bindmounts/shared,mp=/shared`. vzdump never backs up a bind mount, so the pool needs its own backup.
Windows guest	VM	Proxmox's docs: other operating systems like FreeBSD or Windows can't run inside a container.
Firewall (OPNsense, pfSense)	VM	Both are built on FreeBSD. Netgate says checksum offloading must be disabled on VirtIO interfaces.
DNS filter (Pi-hole, AdGuard Home)	LXC	A plain Linux service with no module, device or other OS to ask for, and a container's runtime cost is "low, usually negligible".

Anything not listed goes through the tree.

The decision tree

New workload in Proxmox?
│
├─ Docker/Compose stack or Home Assistant OS? → VM
│
├─ Windows, FreeBSD or any non-Linux OS? → VM
│
├─ One guest owns a whole PCI device (GPU, HBA, NIC)? → VM
│
├─ Needs its own kernel or a module the host lacks? → VM
│
├─ Untrusted or public-facing code? → VM
│
├─ Must keep running while it moves between cluster nodes? → VM
│
└─ Everything else → LXC container
   (a Linux service, trusted code; an iGPU render node or a host directory can be passed in)

When a service could go either way, I'd start it in a VM. Moving it into a container later is a planned job; finding out three months in that a container needs the whole GPU is a rebuild.

What the overhead looked like on my box

Measured on a Beelink SEi12 Pro (N150, 16GB RAM, 512GB NVMe) running Proxmox VE 8.x, then the current release. Treat the absolute megabytes as 8.x-era; the container-versus-VM gap is structural, so the shape holds.

Metric	LXC (Debian 12, idle)	VM (Debian 12, idle, virtio)
RAM used by guest	~55 MB	~280 MB
CPU overhead	<1%	1 to 3%
Storage IO vs bare metal	~98%	~94 to 97%
Network throughput vs bare metal	~99%	~97%
Boot time	0.5 to 1.5 seconds	8 to 20 seconds
Backup size (Debian + 1 app)	~400 MB	~2.0 GB

The storage IO gap closes significantly when using virtio-blk with io_uring.

Proxmox-specific gotchas

Unprivileged is the default. The container's root UID 0 is mapped to an unprivileged user on the host, by default in both the Create CT wizard and pct create. The LXC project calls a privileged container unsafe and doesn't treat new escapes from one as worthy of a CVE. Keep privileged containers for trusted work.

NFS or SMB inside a container. The NFS and SMB/CIFS boxes in the container's Features dialog are marked "privileged only", and pct.conf(5) warns that an NFS mount can block the host's I/O completely and prevent it from rebooting. Mount the share on the Proxmox host and bind-mount it into the container. The container stays unprivileged.

Docker inside a container. An unprivileged container needs keyctl=1 and nesting=1. The web interface has turned nesting on for new unprivileged containers since Proxmox VE 7.1. VE 9.1 can create a container straight from an OCI image, but running application containers that way is still a technology preview, and Compose support is on the roadmap, not in 9.2.

Kernel modules. A container runs on whatever modules the host kernel has. pct.conf(5) lists force_rw_sys, fuse, keyctl, mknod, mount and nesting, and none of them loads a module. WireGuard isn't a reason for a VM: it's been in the mainline kernel since Linux 5.6, and Proxmox VE 9.2 ships kernel 7.0. A module the Proxmox kernel doesn't carry, a different ZFS version or an out-of-tree NIC driver is a reason.

Live migration. In a cluster, qm migrate <vmid> <target> --online moves a running VM; passed-through PCI or USB devices block it, local disks don't. A running container can't live-migrate. pct migrate --restart shuts it down (killing it after 180 seconds by default), copies it and starts it on the target.

Snapshots depend on the storage. Container snapshots need ZFS, LVM-thin or Ceph RBD (BTRFS is a technology preview). On directory, NFS, CIFS or plain LVM storage a container gets none. A VM also gets them on file storage when its disk is qcow2.

Backups

A container's snapshot-mode backup needs every backed-up volume on snapshot-capable storage; without it, suspend mode rsyncs to a temporary directory and needs space for the copy. Bind and device mounts are never backed up. A VM's snapshot mode is a live backup on any storage type, and with the guest agent running it calls guest-fsfreeze-freeze and guest-fsfreeze-thaw.

The layout I'd use: the ZFS pool stays on the Proxmox host, datasets bind-mount into unprivileged containers for native Linux services like Jellyfin or a Samba share, and Compose stacks go in a VM. The pool needs its own backup.

Jellyfin in Docker: find out which side of the container is wrong

LK Wood IV — Thu, 05 Nov 2026 13:39:04 +0000

The setup wizard opens on port 8096, but the movie folder looks empty. Switching on hardware acceleration won't fix that. The first question is simpler: does the container see the same files you do?

Suppose Compose maps /mnt/media/movies:/data/movies. The left side is a directory on the host. The right side is where the Jellyfin process sees it. In the library picker, use /data/movies. To compare the two views, run these from the directory containing your Compose file, assuming the service is named jellyfin:

ls /mnt/media/movies
docker compose exec jellyfin ls /data/movies

An empty host directory points you back to the media or NAS mount. Files on the host but no files inside? Check the bind mount in the running container. If Jellyfin still cannot read a file that this command lists, check the service user's permissions; an interactive command and the server may run as different users. There's no reason to change ownership of the whole library just to find out.

If Compose never gets far enough to open the wizard, read the first network error. A sample with an external network named proxy expects that network to exist already. For a LAN-only test that doesn't use a reverse proxy, remove the service's reference to proxy and the top-level declaration for that network. Leave the port mapping in place.

I'd leave the GPU out of this test.

Once Jellyfin can find and play the file, the full Compose walkthrough at TechFuelHQ shows where to add the optional proxy network and GPU device.

LM Studio vs Ollama on an RTX 5080: The Settings Matter More Than the Wrapper

LK Wood IV — Sat, 31 Oct 2026 12:01:50 +0000

Adapted from LM Studio vs Ollama on an RTX 5080, published on TechFuelHQ.

If you are choosing between LM Studio and Ollama, choose by workflow, not by benchmark folklore.

I tested both on the same RTX 5080, loading the same GGUF bytes wherever the formats allowed it. Ollama was modestly faster at dense-model decode. LM Studio was faster at prompt prefill. Neither wrapper produced the dramatic gap people often attribute to it.

The largest performance differences came from memory settings.

The short version

Use Ollama when the model is infrastructure:

A background service
An API for another application
A Docker-based stack
Something that should start with the machine and stay out of the way

Use LM Studio when the model is an interactive appliance:

A graphical model browser
A chat interface
Per-model controls exposed in one place
An OpenAI-compatible local server with visual configuration

On this test system, the applications were within 14% of one another under matched conditions. A single bad setting produced a 23% loss in LM Studio and a 3.4× slowdown in Ollama.

What I measured

Test system:

RTX 5080 16 GB
Windows 11
NVIDIA driver 610.88
Ollama 0.32.15
LM Studio 0.4.21 with llama.cpp CUDA runtime 2.29.1
Context length 4,096
Full GPU offload
Temperature 0
Seed 42
One serving slot
Five fresh-prompt runs per decode cell

For Llama 3.2 3B and Qwen 2.5 14B, both applications loaded identical, hash-verified GGUF files.

Model	Application	Decode	Prompt prefill	GPU memory
Llama 3.2 3B Q4_K_M	Ollama	350.5 tok/s	17,862 tok/s	3,760 MiB
Llama 3.2 3B Q4_K_M	LM Studio	316.0 tok/s	20,337 tok/s	3,808 MiB
Qwen 2.5 14B Q4_K_M	Ollama	102.2 tok/s	5,038 tok/s	10,356 MiB
Qwen 2.5 14B Q4_K_M	LM Studio	97.6 tok/s	5,567 tok/s	10,405 MiB
gpt-oss 20B MXFP4	Ollama	213.7 tok/s	9,187 tok/s	13,570 MiB
gpt-oss 20B MXFP4	LM Studio	242.8 tok/s	9,618 tok/s	12,533 MiB

Ollama decoded the two dense models 5-11% faster. LM Studio prefilled every tested model 5-14% faster.

The gpt-oss row is not an identical-file comparison. Ollama ships its own gptoss conversion; LM Studio used the upstream ggml-org MXFP4 GGUF because its runtime rejected Ollama’s architecture-tagged blob. Engine and conversion differences both contribute to that result.

Both applications are packaging the same underlying server

The process captures showed llama-server.exe serving the model on both sides. Ollama runs its vendored build; LM Studio downloads its own llama.cpp runtime.

That common engine explains why the dense-model results land close together. The wrapper affects defaults, model management, memory behavior, and workflow more than it changes the fundamental inference path.

Versions still matter. Ollama’s Llama 3.2 3B result on this machine moved from roughly 319 tok/s to 351 tok/s across fourteen patch releases and six days. A local-LLM benchmark without application and runtime versions is a snapshot without a timestamp.

LM Studio’s automatic offload cost 23%

LM Studio initially ran gpt-oss 20B at about 186 tok/s with its stock automatic GPU-offload setting.

I first normalized context length, slot count, and offload together, which raised the result to roughly 243 tok/s. To isolate the cause, I repeated the stock configuration and changed only the offload slider.

The result was 244.9 tok/s.

Automatic offload had held part of the model on the CPU even though the card could run the tested configuration fully on the GPU. LM Studio did not surface a warning. Moving one slider recovered the entire gap.

Before comparing applications, confirm that LM Studio has not silently chosen partial CPU offload.

Ollama’s context setting caused a 3.4× slowdown

The same class of failure appeared in Ollama.

At a 4,096-token context, Llama 3.2 3B stayed fully GPU-resident and decoded at about 351 tok/s. This machine still had Ollama’s application-level context slider set to 256k from earlier work. Ollama clamped that request to the model’s 131,072-token maximum.

The resulting footprint grew to about 18 GB and split across system RAM and VRAM. Decode fell to 102 tok/s.

Nothing about the model or application version changed. The oversized KV cache alone turned a 351 tok/s result into a 102 tok/s result.

If Ollama is unexpectedly slow:

Check the configured context length.
Run ollama ps.
Confirm that the model and KV cache are not spilling into system RAM.
Retest with the context length the workload actually needs.

VRAM was effectively a tie; system RAM was not

Where both applications loaded the same file, GPU-memory use differed by less than 50 MiB:

3,760 vs. 3,808 MiB for Llama 3.2 3B
10,356 vs. 10,405 MiB for Qwen 2.5 14B

System RAM showed a larger difference.

With no model loaded, the Ollama service tree used 78-132 MB across the quiet-window observations. LM Studio’s GUI and server used 709-928 MB.

With gpt-oss resident, LM Studio’s process tree reported about 13 GB of system RAM alongside its 12.5 GB VRAM allocation. Ollama’s runner sat around 2.1 GB. Much of LM Studio’s total was memory-mapped file cache and therefore evictable, but it still matters on a machine with limited RAM or other services running.

The model files can be shared

LM Studio imported the Ollama blobs for Llama 3.2 3B and Qwen 2.5 14B directly. Using the hard-link option let both applications name the same physical bytes on disk. Hash checks confirmed that the imported files matched Ollama’s stored blobs.

The exception was gpt-oss 20B. Ollama’s blob declares the gptoss architecture used by its fork, while LM Studio’s upstream llama.cpp runtime rejected it as unknown. That model required the upstream ggml-org GGUF on the LM Studio side.

For most GGUF models, running both applications does not require maintaining two full weight libraries.

Which should you install?

Choose Ollama if you want a lightweight service with simple API and container integration. Its dense-model decode edge was real on this system, and its idle RAM footprint was much smaller.

Choose LM Studio if you want visual model discovery, a chat interface, and granular per-model controls. Its prompt-prefill performance was consistently better here, and the GUI makes configuration easier to inspect, provided you verify the automatic offload decision.

Install both if your work genuinely uses both modes. They coexisted on this card on ports 11434 and 1234, and two resident 3B models used 7,000 MiB of total GPU memory including the desktop baseline.

The actionable result is not that one wrapper is universally faster. It is this:

The application gap was at most 14%. A wrong memory setting was worth up to 240%.

Check GPU offload. Check context length. Record the application and runtime versions. Then benchmark the workflow you actually run.

The complete methodology, raw-result links, RAM observations, model hashes, limitations and the same-GPU comparison dataset are in the full LM Studio vs. Ollama comparison linked at the top.

Docker Exit Code 137: Prove OOMKilled Before Raising Memory

LK Wood IV — Mon, 05 Oct 2026 06:57:30 +0000

Adapted from Docker Exit Code 137: Prove OOMKilled Before Raising Memory, published on TechFuelHQ.

A container has stopped with exit code 137. Before restarting it or increasing its memory limit, capture its identity, state and failure window. Those records help distinguish a container memory limit from host pressure, a stop timeout, or an external kill.

The number alone cannot tell you which happened. Bash reports fatal signals as 128 + the signal number, and Linux assigns SIGKILL number 9. But Docker returns the container command's exit status, so the command can return 137 itself. Docker also documents two non-memory routes to SIGKILL: docker kill sends it by default, while docker stop escalates to it after the timeout.

Capture one container and one time window

Replace these example values. Keep an explicit timezone: Docker events otherwise interprets timestamps in the client's local timezone.

CONTAINER='replace-with-name-or-id'
SINCE='2026-10-03T18:20:00-05:00'
UNTIL='2026-10-03T18:30:00-05:00'

First, read the stopped container's state and configured limits with Docker inspect. Save the full container ID with the output.

docker inspect --type=container \
  --format 'id={{.Id}} name={{.Name}} image={{.Config.Image}} exit={{.State.ExitCode}} oom_killed={{.State.OOMKilled}} started={{.State.StartedAt}} finished={{.State.FinishedAt}} error={{json .State.Error}} memory={{.HostConfig.Memory}} reservation={{.HostConfig.MemoryReservation}} memory_swap={{.HostConfig.MemorySwap}} oom_kill_disable={{json .HostConfig.OomKillDisable}} restart_count={{.RestartCount}}' \
  "$CONTAINER"

Next, collect the event sequence. Docker exposes separate oom, kill, die, stop and restart events. Its retained history covers only the last 256 events. Collect it promptly.

docker events \
  --since "$SINCE" \
  --until "$UNTIL" \
  --filter type=container \
  --filter container="$CONTAINER" \
  --format '{{json .}}'

docker logs --timestamps --since "$SINCE" --until "$UNTIL" "$CONTAINER"

Application logs can preserve the last completed operation or a shutdown request. A missing final message does not establish a kernel kill.

On a systemd host, collect kernel and daemon logs too. The UTC timestamps below cover the same example interval. These queries select the current boot; journalctl documents time and boot filtering.

JOURNAL_SINCE='2026-10-03 23:20:00 UTC'
JOURNAL_UNTIL='2026-10-03 23:30:00 UTC'

journalctl -k --boot=0 --since "$JOURNAL_SINCE" --until "$JOURNAL_UNTIL" --no-pager \
  | grep -Ei 'out of memory|oom-kill|killed process|memory cgroup'

journalctl -u docker.service --boot=0 --since "$JOURNAL_SINCE" --until "$JOURNAL_UNTIL" --no-pager

If the incident preceded this boot, run journalctl --list-boots. Choose the boot containing the incident and replace --boot=0 in both commands with --boot=THE_32_CHARACTER_BOOT_ID. On other hosts, use their actual kernel and daemon log mechanism.

Identify the memory boundary

State.OOMKilled=true means Docker recorded an OOM-killed state. It does not establish whether the container's own limit, a parent cgroup, or host pressure was responsible. Correlate it with the event timeline and kernel record.

A false flag is not an all-clear. Without matching evidence, keep the cause unresolved.

The inspect field memory is the container's hard limit in bytes. Zero means Docker configured no per-container hard limit; it says nothing about a parent boundary or the host's capacity. Docker distinguishes hard limits from soft reservations and warns about host OOM when memory is exhausted.

Where the host retains the container's cgroup, inspect that too. Locate the path through the host's runtime configuration. Do not borrow another machine's path.

For cgroup v2:

CGROUP_PATH='/replace/with/verified/container-cgroup-path'
cat "$CGROUP_PATH/memory.max"
cat "$CGROUP_PATH/memory.high"
cat "$CGROUP_PATH/memory.events"
cat "$CGROUP_PATH/memory.events.local"

The kernel's memory-controller documentation gives these files distinct meanings:

memory.max is the hard limit.
memory.high applies reclaim pressure without itself invoking the OOM killer.
An increase in the exact cgroup's local oom counter indicates allocation was about to fail at that cgroup's limit.
An oom_kill increase counts processes in the cgroup killed by an OOM killer. It does not identify the limiting boundary or prove the victim was the container's PID 1.
memory.events includes descendant events; memory.events.local stays local to that cgroup.

Record unavailable counters as unavailable. A replacement container's counters cannot fill the gap. Hosts using cgroup v1 need its different memory interfaces, covered in the original guide.

Choose a change the evidence supports

A matching Docker oom event and a nonzero limit still need corroboration. A kernel record naming the limiting cgroup, or a same-window increase in that exact cgroup's local oom counter, helps establish the boundary. Then compare workload peaks with the limit and investigate the application's memory configuration or a leak.

For host pressure, inventory the other workloads and host reserve. Raising one container's limit can move pressure onto the host.

For a stop-timeout escalation, investigate shutdown handling. Docker notes that shell-form ENTRYPOINT and CMD run below /bin/sh -c, which does not pass signals to the executable. Investigate signal handling or the grace period before changing memory.

For an external kill, trace the actor through daemon, service or scheduler records. If no branch is proven, retain the evidence and improve capture for the next occurrence.

Keep a short incident record:

Container ID and image:
Incident timestamp and timezone:
ExitCode / OOMKilled / RestartCount:
Configured container and proven parent limits:
Same-window Docker events:
Kernel victim and limiting cgroup, if identified:
cgroup version, exact path and counter changes:
Unavailable evidence:
Current classification, including unknown:
One change to test / result / timestamp:

The commands above collect evidence. They do not restart the container or change its limits. A restart may restore service while the cause remains unknown.

Disclosure: This article is adapted from TechFuelHQ's sourced guide. The original documents a Docker and Linux documentation review on October 3, 2026; no Docker-host OOM experiment was performed for it, and this adaptation claims no new testing.

Self-hosting break-even: $23/month of SaaS, a $170 mini PC, about 9 months

LK Wood IV — Thu, 01 Oct 2026 01:16:42 +0000

Replacing $23/month in SaaS subscriptions (Google One 2TB + 1Password + Plex Pass) with a $170 mini PC drawing 15W idle breaks even in about 9 months. Replacing $10/month in Google storage with an $800 server never pays back.

Both answers come out of the self-hosting break-even calculator on my site. The gap between them is the argument. What you're replacing is the most important variable.

The ongoing side still has a bill

Self-hosting doesn't cost zero after the hardware. For a minimal stack it looks like this:

Cost item	Typical amount	Notes
Electricity	$1–4/mo	10–30W idle × 24/7 at $0.184/kWh
Backblaze B2 backup	$0.60–2/mo	~100–300GB after deduplication
Domain name	$1–1.25/mo	$12–15/yr amortized
Total ongoing	$3–7/mo	Before hardware amortization

Electricity is the biggest line. Its rate matters more than most guides acknowledge. The default is $0.184/kWh, the EIA May 2026 US residential average, where a 15W mini PC running 24/7 costs about $24/year, while at $0.13/kWh (roughly the cheapest US states, Idaho and Utah, in EIA's May 2026 residential table) the same box costs about $17/year and at California's $0.333/kWh it costs about $44/year. Use the rate on your own bill.

Two questions, kept apart on purpose

The calculator answers two different questions from the same inputs. The monthly self-host figure and the year-by-year table amortize the hardware over the lifetime you pick, so a $300 mini PC used for 5 years costs $5/month in hardware amortization and the same box used for 7 years costs $3.57/month. Break-even treats the hardware as upfront instead. It's the number of months of operating savings (SaaS cost minus electricity, maintenance and backup, with hardware amortization excluded) that it takes to recoup the purchase price.

Here are the calculator's own outputs for its defaults: Google One 2TB at $9.99/mo, Plex Pass at $6.99/mo and 1Password Families at $5.99/mo, a 5-year lifetime, 15 W idle, $0.184/kWh, $15/yr maintenance and Backblaze B2 at $1.20/mo. Only the hardware changes.

Hardware	SaaS / month	Self-host / month	Monthly savings	Break-even	5 years
$300 mini PC (default)	$22.97	$9.46	+$13.51	1.4 yr	+$810
$170 N150 mini PC	$22.97	$7.30	+$15.67	9 mo	+$940

On the $170 box the ongoing costs come to about $4.50/month (electricity $2.01, maintenance $1.25, off-site backup $1.20), or about $7.30/month once the $170 is spread over five years.

When the answer is "Never"

Now the $800 server against $10/month of Google storage. It never pays back. The operating savings alone would need about 12 years, more than two 5-year hardware lifetimes, so the calculator returns "Never" rather than a payback date.

That's deliberate. When break-even lands past the hardware lifetime you selected, the tool reports "Never", because a payback you can only reach after buying a replacement machine is not a payback. It's the same condition as the monthly-savings figure going negative.

Flip the inputs and it gets quick. Replacing $50/month in cloud subscriptions with a $200 mini PC breaks even in under 5 months.

What's worth replacing

The clear wins, where self-hosting is dramatically cheaper and reliable:

Vaultwarden for 1Password Families or Bitwarden Premium
Jellyfin for Plex Pass, with no transcoding session limits
Uptime Kuma for UptimeRobot Solo
Immich for Google One 2TB storage, if you have local storage

Nextcloud (for Dropbox or Google Drive) and n8n (for Zapier) are viable but take more effort. Nextcloud needs maintenance, and n8n has a steeper setup curve.

I'd keep paying for three things. Email, because of deliverability problems from residential IPs and high maintenance. CDN and DDoS protection, which aren't worth running yourself. Calendar sync, which is too fragile for too little savings.

Where the defaults are assumptions

The subscription presets use the vendors' published list prices at capture time. Plans change.

So confirm the current price before deciding, and treat the rest of the defaults the same way. The $0.184/kWh default is an average; your bill's effective rate is the number to use. The 15 W idle draw, $15/year maintenance and $1.20/month backup are my working assumptions for a small mini-PC stack, stated so you can replace them with your own measured numbers. The six hardware presets are street-price estimates for a class of machine. They are not quotes for a named SKU, and they aren't sourced the way the subscription prices are. Type in what you actually paid.

First published on my site, techfuelhq.com. Every number here is copied from it.

Raw data is useful only when the caveats travel with it

LK Wood IV — Sun, 20 Sep 2026 08:03:54 +0000

When comparing public benchmark datasets, the method and limitations should travel with the download. That is the point of the TechFuelHQ dataset hub: the evidence trail is part of the data.

Use it this way:

Open the dataset page before the file. Check the collection date, test setup, attribution, correction history, and dataset-specific license.
Download the CSV or JSON. CSVs work in a spreadsheet or with pandas; JSON works well in scripts and small tools. Keep blanks as blanks instead of silently converting “not measured” into zero.
Follow the reproduction material. Depending on the release, that may be an evidence manifest, a corpus/scorer README, or a Python runner with per-repetition output. Read code before running it and preserve the documented hardware, model, and settings when comparing results.
Cite the dataset version and capture date in anything you publish.

The hub currently includes first-party GPU and local-LLM measurements, Home Assistant voice results, component-reference JSON, and price-observation CSVs. A price row describes its capture date; it is not a live-price claim. The PC-builder reference data stores compatibility attributes and source pages without storing prices.

Browse or download the files.

Disclosure: This is my site.

How to Test a UPS: Charge Is Not Health

LK Wood IV — Wed, 16 Sep 2026 19:31:55 +0000

The number on the front of a UPS is a charge reading. It is not a health reading.

A unit showing full can drop the load the moment it transfers. The display will have been telling you everything was fine right up until the instant it stopped being fine, and it was not lying — it was answering a different question than the one you thought you were asking.

That gap between charged and working is the whole subject here. Sizing the unit is settled territory: VA against watts, runtime against your shutdown window. This is about what comes after you have bought the right size — proving it does the job, on a schedule, before the power goes out and proves it for you.

The built-in self-test is not a runtime test

Most units test themselves. The test covers less than the name suggests.

Schneider's documentation for the Smart-UPS line says the unit self-tests when you switch it on and every two weeks after that, and that during the test it runs on battery for approximately ten seconds (Schneider Electric FA405317). The Back-UPS line runs the same ten seconds on a different clock — Schneider describes the automatic test as happening every seven days after the unit is powered on — and its replace-battery alarm is framed against a standard two-minute runtime limit (Schneider Electric FAQ000267818).

Ten seconds is a genuinely useful test of one thing: the transfer relay closes and the inverter comes up. Keep it enabled. But read what it is measuring. A battery that has lost most of its useful capacity will hold ten seconds without complaint, and it will hold two minutes for a while after that. By the time the automatic test starts failing, you have already been running on a battery that would not have finished a shutdown.

Charge is a percentage. Capacity is minutes. The panel shows you the first one and you need the second one.

An untested UPS is a surge protector with a battery in it

So test on a schedule, and make it a real test.

Connect the load the unit actually protects. Pull the input cord. Watch what the load does at the moment of transfer, and time how long the battery holds before the shutdown you configured actually fires. That one pull exercises the transfer, the inverter, the battery under its real load, and your shutdown chain, in the order they will happen for real.

Nothing else does. A ten-second self-test skips the load. A runtime figure from a spec sheet skips your gear. The UPS runtime calculator will model the curve for you, and the model is worth having as a starting expectation — but a modelled forty minutes and a measured forty minutes are not the same claim, and only one of them is about the battery currently sitting in your rack.

If you would rather not pull a cord on live equipment, NUT will start a deep battery test on hardware that exposes one:

upscmd -u <user> <upsname> test.battery.start.deep

test.battery.start.quick, test.battery.start.deep and test.battery.stop are all standard NUT instant commands (NUT instant command reference), and upscmd -l <upsname> lists what your specific unit supports (upscmd man page).

There is a second reason to test that has nothing to do with the battery. A UPS can fail in a way that takes the load down with it. That is a real failure mode, not a freak event. The box you bought to prevent an unclean shutdown sits in series with everything it protects, and the only way to find out how yours behaves when it goes wrong is to make it transfer while you are standing there rather than at 3am while you are not.

Pure sine, or don't put a server PSU behind it

This one has a mechanism, and the mechanism is published by the people selling the cheaper option.

CyberPower's explanation of its own PFC Sinewave line is that a simulated sine wave produces a zero-output state during the phase change — a gap in the waveform — and that this gap can interrupt equipment running an active-PFC power supply when the unit switches from mains to battery (CyberPower, PFC Sinewave Series).

Read where that failure lands. Not during a brownout, not on a slow degrade — at transfer. The single event the UPS exists to handle is the event a simulated-sine unit is worst at, and active PFC is standard in modern PC and server supplies; CyberPower's own page dates that transition to the last fifteen years.

Simulated sine into an active-PFC supply is asking for trouble on transfer. Pure sine for anything with a server PSU behind it.

USB and NUT, not a network management card

Network management cards cost absurd money next to the UPS they plug into. A UPS network management card is a separate accessory bought on top of the unit, and for a single-site homelab it buys network-side monitoring you can get from a cable.

USB plus NUT does the job and is what I'd run. Three pieces:

usbhid-ups should detect anything implementing the HID Power Device Class, with the amount of data varying by manufacturer and model. NUT lists all MGE, Dell and AMETEK Powervar USB models, the newer Eaton USB models, and specific models from APC, CyberPower, TrippLite, Belkin, Powercom and PowerWalker (usbhid-ups man page). Check your exact model against the compatibility list before you count on it.
upsmon watches for the critical condition — on battery, low charge — sets the forced-shutdown flag, and lets every machine it is monitoring run its own shutdown command with a delay you set (NUT configuration notes).
upscmd gives you the battery tests above and the alarm control below.

That is the entire feature set most homelabs wanted from the card.

If it can't trigger a clean shutdown of what's plugged into it, most of the value is gone. A UPS that only buys you a few minutes of uptime during which nobody is home to act is a very expensive way to delay the same unclean power-off. The shutdown chain is the product. Configure it the day the unit arrives, then test that it fires — which is the same plug-pull from two sections up, and the reason that test is worth doing properly.

The alarm will go off at 3am

It will. The alarm is standard equipment, and the first time it fires is the worst possible moment to be learning where the mute button is.

Decide now what you want it to do, and set it now. NUT exposes beeper.disable, beeper.mute, beeper.enable and beeper.toggle as instant commands (same reference), so this is one upscmd call, done while you are awake and thinking clearly about whether you actually want an audible alarm in that room.

Batteries are a consumable

Plan for the replacement rather than being surprised by it. Sealed lead-acid cells are on a several-year cycle, and third-party replacements are standard practice — not a corner cut.

Schneider puts most APC batteries at three to five years and notes that every 8°C (15°F) of extra operating temperature halves that life (Schneider Electric FA158934). That second figure is the one people miss. A UPS in a warm closet is not on the same schedule as the same UPS in a basement, and if you have put yours in the warm closet, the replacement year on your calendar is optimistic.

Which puts you back at the test. The only way to know where your battery is on that curve is to have measured it recently under load.

What I'd do: pure sine, USB, NUT, and a plug-pull on a schedule

Buy a pure sine wave unit sized to your load, connect it over USB, run NUT, and pull the plug on a schedule. No management card. That configuration covers the transfer, the shutdown, the alarm and the tests, and there is nothing left in the card that a homelab with one rack needs.

The plug-pull is the part people skip and the only part that produces information. Put it on a recurring reminder alongside whatever else you check, keep the number you measured, and compare it to the last one. When the measured runtime has fallen far enough that your shutdown no longer finishes inside it, buy cells — before the automatic self-test gets around to agreeing with you.

This is wrong for a few situations. Simulated sine into active PFC — do not, at any price. A consumer unit under a full rack, where the load is past what the unit is rated to hold and the runtime is theatre. And anyone who will not set up automatic shutdown, because at that point the money bought a surge protector with a battery in it, which is where this started.

Testing does not make a UPS more reliable. It tells you whether the one you own is still doing the job, which is a different and more useful thing than a green light. And none of it replaces keeping backups somewhere else — a clean shutdown protects the pool, not the data.

Originally published on techfuelhq.com.

How to Install Proxmox VE (2026): Install + Update Reference

LK Wood IV — Sat, 04 Jul 2026 16:35:39 +0000

Installing Proxmox VE is genuinely easy. The graphical installer is a few screens, and it writes itself to disk in a couple of minutes. What trips people up is not the install itself: it is the first fifteen minutes afterward, where a default install points at a repository you cannot use without paying, and the longer-term question of how you keep the thing updated once it is running.

This is the generic reference for both. It is hardware-agnostic on purpose: the steps below apply to a mini PC, a used office desktop, an old gaming rig, or a rack server. If you want a hands-on, click-by-click walkthrough on a specific small box, the Proxmox mini PC setup guide is the hardware-specific companion to this one. If you are still choosing hardware, start with the Proxmox hardware requirements. And if you already run VE 8 and want to jump to VE 9, that is a different, planned operation covered in the 8-to-9 upgrade gotchas.

Everything below is cited to the official Proxmox documentation. The current release as of this writing is Proxmox VE 9.2-1 (released May 21, 2026), built on Debian 13 "Trixie." If a command or file path is here, it is real and current for VE 9.

Part 1: The clean install (any hardware)

Step 1: Download and verify the ISO

Grab the latest Proxmox VE ISO from the official downloads page. As of June 2026 that is the VE 9.2-1 installer, about 1.7 GB.

Do not skip the checksum. The download page publishes a SHA256 value next to the ISO. After downloading, compute the hash and compare it to that published value:

# Linux / macOS
sha256sum proxmox-ve_9.2-1.iso

# Windows (PowerShell)
Get-FileHash proxmox-ve_9.2-1.iso -Algorithm SHA256

If the two strings do not match, the download is corrupt or tampered with. Delete it and re-download. This takes ten seconds and it is the one verification step that matters before you write installation media.

Step 2: Write the USB installer

A USB stick is the standard install medium. The tool depends on your OS, and the official guidance is specific about which ones work:

Linux: use dd. Identify the USB device first with lsblk, then write with dd bs=1M conv=fdatasync if=./proxmox-ve_9.2-1.iso of=/dev/XYZ (replace /dev/XYZ with your actual USB device; getting this wrong overwrites the wrong disk).
Windows: Etcher works with no configuration. Rufus also works, but you must select DD mode when it prompts, not ISO mode.
macOS: convert the ISO to a raw image, then write it (see the official media-prep page for the exact hdiutil and dd sequence).

One specific warning from the docs: do not use UNetbootin. It is incompatible with the Proxmox installer.

Step 3: Boot the installer and pick your filesystem

Plug the USB into the target machine, power on, and bring up the boot menu (commonly F11, F12, or Del). Select the USB device, then choose Install Proxmox VE.

Two decisions matter. Target disk and filesystem: select the SSD or NVMe you want Proxmox on, and be careful not to pick the USB installer drive by accident.

Filesystem	When to choose it
ext4 (default)	Single-disk machine. Simple, fast, reliable, uses an LVM-thin pool Proxmox manages natively. The right first-install answer.
ZFS	Two or more drives and you want a mirror or RAID-Z, plus snapshots, checksums, and self-healing. Wants meaningful RAM for its cache.
XFS	Offered with LVM, but far less common in Proxmox setups than ext4.
Btrfs	A technology preview. Not recommended for a production-style install yet.

The official installer note is blunt that ZFS on top of any hardware RAID is unsupported and can cause data loss, so if you run ZFS, give it the raw disks. For a first build on one drive, choose ext4 and move on.

Network and password: set a hostname, then set a static IP outside your DHCP range so the web UI always lives at the same address. Set a strong root password. The installer builds a Linux bridge called vmbr0 on your first NIC so VMs and containers can reach the network. Click install; it writes to disk in a few minutes and reboots.

Step 4: Reach the web interface

Point a browser on another machine at the IP given during install, on port 8006:

https://your-ip:8006

Note the https and the :8006. Plain http or a missing port is the single most common "it didn't work" mistake, and the install is almost certainly fine. You will get a certificate warning because Proxmox uses a self-signed cert; accept it and log in as root.

Part 2: The first fifteen minutes (the repository fix)

This is the part generic install guides skip, and it is the one step every Proxmox install needs. A fresh install points apt at the enterprise repository, which requires a paid subscription. Without a key, every apt update ends in 401 Unauthorized and your package lists never refresh.

Proxmox VE 9 also changed the repository file format to the deb822 .sources format, so the files look nothing like the one-line sources.list entries from VE 8.

Disable the enterprise repository

Open the node shell (web UI, your node, Shell) and edit /etc/apt/sources.list.d/pve-enterprise.sources, adding a single line so it reads Enabled: no. That suppresses the enterprise repo without deleting it.

Enable the no-subscription repository

Create the no-subscription sources file with the exact deb822 contents the docs publish for VE 9:

# /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

You can do all of this from the web UI instead: node, Updates, Repositories, Add, pick No-Subscription, then highlight the enterprise row and click Disable. The GUI writes the same files for you.

The no-subscription repo ships the same packages as enterprise without a key. Proxmox is explicit that these are "not always as heavily tested and validated," so it is fine for a home lab but is not their recommendation for production.

Run the first update

apt update
apt full-upgrade

Use full-upgrade, not plain upgrade, more on why in Part 3. Reboot if a new kernel was installed. The subscription-nag popup at login is cosmetic; click OK and move on.

Part 3: How to update Proxmox over time

Once Proxmox is running, "update" means two very different things, and conflating them is where homelabs get into trouble.

Routine updates (within a major version)

Normal maintenance, keeping VE 9 current as point releases ship (9.1 to 9.2). From the shell, apt update then apt full-upgrade; or in the web UI, select the node, open Updates, Refresh, then Upgrade.

Why full-upgrade and not apt upgrade? Plain upgrade refuses to install anything that requires a new dependency, and on Proxmox that means the kernel and the pve-manager stack get held back, exactly the packages you want updated. full-upgrade installs them. A reboot is only needed when a new kernel arrives.

Major upgrades (across major versions)

Moving from VE 8 to VE 9 is a different animal. It crosses to a new major version, which moves the underlying Debian base and kernel, and it carries real breaking changes: LVM autoactivation defaults change, network interfaces can be renamed, and PCI passthrough can need attention. That is a planned event with its own pre-flight checklist: back up first, run the pve8to9 --full checker, pin your NIC names, and have console access that is not the web GUI. The full procedure is in the Proxmox VE 8 to 9 upgrade guide. VE 8.4 gets security and bug-fix updates until August 2026, so there is no pressure to rush.

Common install gotchas

apt update returns 401 Unauthorized. You are still on the enterprise repository. Disable it and enable pve-no-subscription (Part 2). This is the number-one new-user issue.
The web UI will not load. You used http instead of https, or forgot :8006. The correct URL is https://your-ip:8006.
VMs will not start ("KVM not available"). Hardware virtualization (Intel VT-x or AMD-V) is disabled in the BIOS/UEFI. Reboot into firmware and enable it, plus IOMMU (VT-d / AMD-Vi) if you plan passthrough.
You picked ZFS and the host feels short on RAM. ZFS reserves RAM for its cache. Size it deliberately.
You accidentally installed onto the USB stick. Always confirm the target disk in the installer is your internal SSD/NVMe.

After the install: what to build

For a screen-by-screen walkthrough on a specific small machine, follow the Proxmox mini PC setup guide.
For each service, decide between a container and a full VM. The LXC vs VM in Proxmox guide has the decision tree.
To size your box, how many VMs and containers your RAM and cores can support with ZFS overhead included, the Proxmox capacity planner does the math.

The install is the easy part. The repository fix is what makes updates work, and knowing the difference between a routine update and a major upgrade is what keeps the box healthy for years.

Sources

Originally published at techfuelhq.com.