Frank Zhang, writing on dev.to, hit this while monitoring a Proxmox VE environment with OpsHome NOC [20]. Proxmox needs the VirtIO balloon driver and its Windows service available before it can obtain useful guest memory statistics at all [8]. His trace shows the guest half of that path working and the host half absent, which leaves the statistics path incomplete, so the host's memory information does not reflect the real Windows state and monitoring inherits that upstream figure [9]. The conclusion he draws is that the VM configuration was the root cause, not the monitoring software [10].
The overshoot is the tell, visible before you even read a config file: the host's used figure exceeded the guest's entire allocation by 0.2 GB [18], and a number larger than the total simply cannot have been measured inside the guest, which means whatever was being graphed tracked allocation rather than consumption.
The spread confirms it, with the host view running 90 to 100 percent against Task Manager's 30 to 50 percent [2], a gap of 40 to 70 percentage points depending on which ends you compare [19]. Zhang's advice is not to reach for the obvious culprits here, whether that's a Windows memory leak, a wrong monitoring threshold, or a monitoring app doing bad arithmetic [17].
Checking the guest first was the right order, and it returned a false all-clear: `Get-Service *balloon*` reported BalloonService Running [5]. A service can be perfectly healthy with nothing attached to the other end of the pipe.
For this to be your bug rather than an interesting anecdote, your dashboard has to read the host's view of the guest. That is the path described here, from incomplete guest statistics through to the monitoring layer [9]. A collector running inside Windows is not on that path and will keep reporting Task Manager's number, correctly, while the host disagrees with it.
Setting minimum memory equal to memory works because the device only reclaims down to the floor, and here the floor is the ceiling. You get the statistics channel and no reclaim behaviour. The reason this configuration survives unnoticed for months is that nothing else breaks: the guest boots, applications, network and disk all work normally [11], and the discrepancy only surfaces when you put Task Manager, the Proxmox figures and the monitoring data side by side [12].
One thing the writeup does not settle is why the Ubuntu VMs on the same host read normally [4]. Their balloon setting is not given. Read that as a prompt to diff per-VM config, not as a claim about guest operating systems.
The general shape is worth keeping. A hypervisor memory percentage is a claim about a per-VM data path, and `balloon: 0` renders identically to a saturated guest [7].
