5:06 a.m.
Hi Daniel,
Thank you very much for the quick answer. Now it is clear how this memballooning driver
works, and how it can be managed manually.
I really appreciate your answer.
Regards,
Csongor
-----Original Message-----
From: Daniel P. Berrangé <berrange(a)redhat.com>
Sent: Thursday, September 17, 2020 11:49 AM
To: Sprencz, Pal Csongor (GE Healthcare) <PalCsongor.Sprencz(a)ge.com>
Cc: libvirt-users(a)redhat.com
Subject: EXT: Re: KVM/QEMU Memory Ballooning
On Thu, Sep 17, 2020 at 09:06:51AM +0000, Sprencz, Pal Csongor (GE Healthcare) wrote:
In short we have a ScientificLinux7 base host OS system, on top of
that I would want to run a KVM/QEMU virtual machine.
The kvm version is used on the host OS is the following.
qemu-kvm-common-1.5.3-173.el7_8.1.x86_64
libvirt-daemon-driver-qemu-4.5.0-23.el7_7.6.x86_64
qemu-kvm-1.5.3-173.el7_8.1.x86_64
The guest Linux OS is Suse.
The VM cfg does contain the mem balloon device configuration.
Inside of the VM we have a Kubernetes. The host system has 64GB, the
VM has maxmemory and currentmemory set to 32GB.
Ok, so even with the VM running, your host has many 10's of GB of free memory
available for other tasks.
I would like to ask you, how we can test that the memory ballooning
mechanism works? Does it works on this version or not. What I see on
the host level, if I put under stress the host with a hugh memory
allocation, in that case the VM resident memory size it is decreasing,
but it not decrease so much as it is expected, and it started to swap
out to host swap disk. The VM on idle state it has 32GB total memory
and 21GB free memory. And what I see the RSS size of the qemu is
decresing with 5-6GB.
I fear you might be mis-interpreting what the balloon device actually does.
It is a totally *manual* mechanism. You have booted the guest with 32GB set as maxmemory
and currentmemory. So initially the guest will have its full 32GB available and no balloon
driver activity will take place.
The balloon driver will only do something when the host administrator
*explicitly* sets a balloon target in QEMU. This is doable via the libvirt
virDomainSetMemory API / virsh setmem command.
There is *nothing* in either libvirt or QEMU that monitors host memory pressure, nor
anything that automatically sets balloon driver targets.
It is possible to create an application that monitors host memory and uses the libvirt
APIs to set the ballon driver. That is outside the scope of what libvirt does as a core
project. There have been 3rd party projects that try todo this though, such as oVirt's
"mom" app (Memory Overcommit Manager).
Do you have any procedure, how it can be tested? Or there is any log
where I can see that the memory ballooning is started to work?
So the out of the box behaviour if you have host memory pressure is that QEMU will get
pushued out to swap. You need to make sure you have enough swap to cope with the worst
case memory load on the host to avoid risk of the OOM Killer waking up.
Finally note that QEMU's default behaviour will not make guest RAM resident when it
starts up. A guest with 32 GB of RAM configured may only use 1 GB initially. Further pages
of guest RAM only become resident as the guest OS touches each page.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|