The host looked out of memory, and wasn't
The readout from free -h on the Proxmox host: 15Gi total, 10Gi used, 2.7Gi "free". A big used figure next to a small free figure is exactly the shape that starts a memory panic, and it's the wrong shape to trust. The number that decides anything is the one after it — 5.5Gi available, counting the reclaimable buffer/cache. Available is what can actually be handed to a new process; free is just memory currently doing nothing. Look at available first, every time.
The guests disagreed with the host
Inside both guests the picture was nothing like the host's. One VM configured with 5.8Gi, using 1.1Gi. The other configured with 3.6Gi, using 932Mi. Neither guest was anywhere near its allocation, yet the host showed the allocations pinned and unavailable.
My read on it: KVM reserves a VM's full configured RAM the moment it boots, regardless of what the guest does with it. That's a static reservation, not a live measurement — so the host's tightness was a configuration artifact, not real demand. The mistake worth remembering is diagnosing host memory pressure from the host side alone. The host tells you what was allocated. Only the guest tells you what was used.
The balloon line that isn't there
qm config for both VMs: no balloon: line in either. In Proxmox, an absent balloon: line silently defaults to the max, which means there's no floor below the max for the stat daemon to shrink toward — functionally the same as ballooning being off entirely, even when the hardware tab makes it look enabled. If a VM's memory panel ever looks like it's doing something, this is the check that settles it.
Decision: left as-is. Setting a balloon value would give the host real headroom back, but usage was light and stable and the added complexity wasn't worth it yet. Revisit if VM memory pressure increases — that was the trigger I picked, so use it.
What to buy instead
Limited budget, one question: the next highest-value hardware purchase. The RAM answer fed straight into it, because the same test — what does the measurement actually show — applies to all four candidates.
- A second compute node: no. Both guests are using a fraction of their allocation, so there's no demonstrated need for more compute.
- More storage: no. No real pressure, and SSD prices were running well above normal on a 2026 supply shortage. Bad timing either way.
- A UPS: genuinely useful insurance against dirty shutdowns and disk corruption, but nothing had failed yet for lack of one. Not urgent.
- A managed switch: the winner. VLANs and subnetting are a real chunk of the Network+ exam, and the lab had zero hands-on network segmentation in it at that point.
Bought, not deployed
An entry-level SG300-10 managed switch, $29.98, from a verified, reputable seller. Bought and not yet deployed. VLAN segmentation is flagged as the next major infrastructure phase once other work settles, and the switch's own spec entry in the hardware notes is still owed once it's actually deployed. Until then this is a purchase, not a working segment — don't let future me read these notes as if the lab were already segmented.
Two things to carry forward
Available memory and free memory are different numbers, and only one of them matters. And measured need beats felt need: buying more compute because the host feels tight would have been the wrong call, and the data said so. The switch won on one criterion rather than price or novelty — it was the only candidate that built toward the Network+/SOC-analyst track. That's the reasoning to reuse the next time the budget question comes up.