[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: EXT: Re: KVM/QEMU Memory Ballooning



 
What about running tasks/containers directly on the host? 


-----Original Message-----
To: Daniel P. Berrangé
Cc: libvirt-users 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 redhat com>
Sent: Thursday, September 17, 2020 11:49 AM
To: Sprencz, Pal Csongor (GE Healthcare) <PalCsongor Sprencz ge com>
Cc: libvirt-users 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 :|






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]