3:17 a.m.
What about running tasks/containers directly on the host?
-----Original Message-----
To: Daniel P. Berrangé
Cc: libvirt-users(a)redhat.com
Subject: RE: EXT: Re: KVM/QEMU Memory Ballooning
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 :|