reference console kvm memory highwater 20260715T110326

Console (VM 103 on Finn) is allocated 80G (memory: 81920 in qm config 103). Without a balloon driver, standard KVM never returns touched guest pages to the host: once Console's guest touches a page (e.g. during a heavy build/compile storm), Finn's hypervisor process holds that RAM permanently, even if the guest later reports it as free internally. So Console's internal free -h can show 22G used out of 78G while Finn's qm / host free shows the Console KVM process pinning ~75G.

Why: Justin noticed Finn was at 97G/126G used while Console itself reported only ~29% (22G) used, which looked contradictory. Root cause is the guest/host memory-accounting gap, not a leak or miscalculation.

How to apply: When reasoning about Finn's total capacity or whether it's safe to raise Console's RAM ceiling, always plan for Console eventually touching its full allocation (i.e. treat allocated = committed, not currently-used = committed). Don't be confused by a low internal free -h reading on Console as evidence Finn has slack. If host-side reclaim under pressure is ever wanted, the lever is qm set 103 --balloon <min> (tradeoff: reclaim could slow Console's builds exactly when they're heaviest, which is why it was left off as of 2026-07-15). A full qm shutdown 103 && qm start 103 resets the high-water mark back down to whatever the guest is actually touching at that moment.

[auto-memory session 60d132de-4659-485c-8044-427af0ccce7f, confidence 0.75, mode staged]