Re: [Qemu-discuss] Memory Ballooning for VM Issue

[Jakob Bohm]

On 8/7/2012 2:03 PM, xuanmao_001 wrote:
> Hi, I have some problems with qemu ballooning.
> I saw the qemu docs. I found the qemu monitor command "balloon" that 
> can request VM to change its memory allocation to value(in MB).
> it requested qemu command line with "-balloon virtio", then I start 
> qemu into monitor mode with memory 512MB.
> first show balloon information.
> (qemu) info balloon
> (qemu)balloon: actual=512
> the command above if like this, I think the balloon device worked fine.
> (qemu) balloon 400
> there was no error when I executed this command.
> but when I executed "info balloon", the result was still 512.
> Is there something wrong?
> please give me some ideas.
Was the Qemu balloon driver and related daemon loaded in the virtual 
machine?
(This is the code that actually takes memory away from the virtual machine's
OS).
> thanks.
> qemu-kvm version: 1.0.1
> linux kernel version: 3.1.6

P.S. (A bit long)

It would be a great improvement of the Balloon feature if it could be run in
a mode where the balloon driver controls its own size based on Guest OS
memory usage and a "memory pressure" level provided by the host machine

For instance, at memory pressure "0.0" the balloon would take no memory,
at "0.7" (etc.) it would take 70% of what the Guest OS reports as free
physical memory.  Between 1.0 and 2.0 it would start taking away memory from
the Guest OS disk cache and other easily reloaded memory (such as untouched
memory mapped file pages) and above 2.0 it would start to make the Guest OS
swap out dirty pages.  On modern Guest OSes there would be some overlap
between the 1.0 to 2.0 and > 2.0 ranges, as the Guest OS redistributes its
available memory in its usual way.

On the Host side, the memory pressure level given to the Balloon driver
would be scaled according to the nice level and ulimits of the qemu
process, with the option to set additional factors via the monitor.

I believe this is how non-qemu virtual machine managers handle ballooning,
and it is much nicer to work with, especially when the memory is not really
overcommitted unless "free" and "Cache" memory is counted as usage.

This would match how CPU overcommit (Idle loop/"steal" cycles) and disk
overcommit (sparse or qcow2 disk images) already work.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded