3 ms·

Whatever you have allocated to those VMs is not available for the host at all. QEMU-KVM will allocate "2GiB" of memory if the VM has 2GiB available.. Even if th

by dijit 4y ago

Whatever you have allocated to those VMs is not available for the host at all. QEMU-KVM will allocate "2GiB" of memory if the VM has 2GiB available.. Even if the linux guest is only using 2% of that actively.

bayindirh 4y ago
That's not correct. With a VirtIO ballooning device [0], you can create faux memory allocations on the VMs and reclaim that allocated memory space back to host. This will increase the memory pressure on the guest, but will provide extra memory to the host. [0]: https://pmhahn.github.io/virtio-balloon/ https://pmhahn.github.io/virtio-balloon/
- dijit 4y ago
  That's not exactly how it works. 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.
  - bayindirh 4y ago
    > 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.
    - dijit 4y ago
      I think we're losing the topic here. 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.

by dijit 4y ago

bayindirh 4y ago

That's not correct. With a VirtIO ballooning device [0], you can create faux memory allocations on the VMs and reclaim that allocated memory space back to host. This will increase the memory pressure on the guest, but will provide extra memory to the host. [0]: https://pmhahn.github.io/virtio-balloon/ https://pmhahn.github.io/virtio-balloon/

dijit 4y ago
That's not exactly how it works. 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.
- bayindirh 4y ago
  > 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.
  - dijit 4y ago
    I think we're losing the topic here. 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.