a virtio balloon is intended to be used in "near OOM conditions" (due to performance implications, mostly)
a normal VM is not doing this.
it's also true that even if it was opportunistic: qemu's memory allocation on the host would take precedence over host filesystem caches which would be consequently evicted.
The reason people really like containers at the moment is partially due to this memory situation, you can "fit" more containers on a host due to better fitting of the memory.
> a virtio balloon is intended to be used in "near OOM conditions"
Of course. This is why you need to plan your VM deployments on your system carefully, even if it's just a desktop system.
> it's also true that even if it was opportunistic: qemu's memory allocation on the host would take precedence over host filesystem caches which would be consequently evicted.
A filesystem cache on the RAM is one of the most opportunistic mechanisms in Linux, and AFAICS, the buffers are the least important allocations on RAM, since they can be re-accessed from disk when necessary. So, the ballooning device enters at very high memory pressure scenarios with almost full swap area.
The truth is, you shouldn't be nearing to this point at any of your systems, running VMs or not.
Lastly, a bare bones Linux system w/o a graphical interface needs comparable memory to a biggish daemon, hence when used smartly, they're invisible sans the context switching load they induce on the system.
The way that qemu allocates memory is that generally it allocates 100% of the memory you've given to the VM (sans virtio balloon, which the VM doesn't really know about and will accidentally use for filesystem caches).
This makes qemu-kvm look like a program that uses a lot of memory, and linux (as a host) doesn't know what's happening inside and is not doing anything smart with free memory inside a VM.
This is true with many caveats, such as KSM (kernel-shared-memory), and the nature of virtio ballooning. This is the foundation of how it's working, which is what my parent comment was asking.
a virtio balloon is intended to be used in "near OOM conditions" (due to performance implications, mostly)
a normal VM is not doing this.
it's also true that even if it was opportunistic: qemu's memory allocation on the host would take precedence over host filesystem caches which would be consequently evicted.
The reason people really like containers at the moment is partially due to this memory situation, you can "fit" more containers on a host due to better fitting of the memory.