Re: Having trouble with ballooning

[Marcelo Tosatti <mtosatti@redhat.com>]

On Thu, Aug 05, 2010 at 01:41:16PM +0200, Moritz Duge wrote:
> Hi,
> I had some trouble while using the ballooning feature of KVM (using
> Ubuntu 10.04 with standard software versions).
> 
> 
> The first scenario:
> 1. Having a guest started by this command: qemu -enable-kvm -m 768
> -balloon virtio -cdrom linux_2.6.34.iso
> The guest is running Linux 2.6.34 including the ballooning driver.
> 2. Entering "balloon 256" and a few seconds later "info balloon" in
> the Qemu monitor. Qemu will report, the guest uses 256mb of memory
> now. The guest is reporting the same (using "free" for example).
> 3. Entering "change ide1-cd0 linux_2.6.18.iso" to change the guests
> CD-ROM to another image, containing a Linux kernel without
> ballooning driver.
> 4. Rebooting the guest.
> 5. After booting the 2.6.18-OS, it will report it has 768mb memory
> (using "free). But Qemu monitor will still tell 256, when entering
> "info memory".
> I know why this happens. But is this a good behaviour? Shouldn't
> Qemu tell something like "maybe 256, but there is no more balloon
> driver in the guest and maybe it uses the full 768 now"???

What version of qemu-kvm are you using? Reporting should work 
properly with a recent qemu-kvm version.

> The second scenario:
> After the first scenario, the guest can also really start using the
> additional 512mb of memory (768 - 256)!!! I think this shouldn't
> happen or at least there should be an option to allow or deny this.
> Or at least least least this should be printed in big letters in the
> man-pages or somewhere else where everyone will read it!
> Because before I experienced this, I assumed I can be sure the guest
> can't get back the memory which was freed using ballooning. So if I
> use the memory freed by ballooning for some other qemu-instances and
> the first one starts to use those memory again, all Qemu instances
> will crash (this is what actually happens in most cases).
> What I'm asking for, is a way to force the guest to stay in the
> memory I assigned by ballooning. And if the guest tries to use more
> memory (maybe because it just unloaded the ballooning driver) the
> guest should crash, but the host shouldn't get in any trouble!!!
> This can be really annoying. I think a very common use-case for
> virtualization is, to run untrusted software or unsecure webservices
> in a vm, so the bad software can't do anything to the host or other
> VMs on the host. But when using ballooning, the bad software can!
> It's no "remote code execution", but the guest can consume a lot of
> memory and cause the host or at least the other VMs on the host to
> crash.

Ballooning requires guest cooperation. If you want to enforce memory
limits, take a look at cgroups (Documentation/cgroups/memory.txt in the
kernel source tree).

> 
> 
> The third scenario:
> 1. Booting a machine with a guest not having a ballooning driver.
> (e.g. qemu -enable-kvm -m 768 -balloon virtio -cdrom
> linux_2.6.18.iso)
> 2. Adjusting the memory by "balloon 512" in the qemu monitor.
> 3. Qemu won't report that it couldn't adjust the memory. Instead it
> will wait until the guest loads a ballooning driver. Is this a good
> behaviour? Shouldn't there be at least a switch in the qemu monitor
> for the command "balloon". So if I use the switch when changing the
> memory (e.g. "balloon -h 256"), qemu won't try to change the memory
> later and it will tell me "error: no ballooning driver found".

You see that that guest has not ballooned down with the output 
from "info balloon".

> 
> Thanks for reading and thanks a lot, if there will be a solution for
> this, specially for scenario two.
> 
> Greetings
> Moritz Duge
> 
> -- 
> Artfiles New Media GmbH | Heidenkampsweg 100 | 20097 Hamburg
> Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95
> E-Mail:support@artfiles.de  | Web:http://www.artfiles.de
> Geschäftsführer: Carsten Bals | Harald Oltmanns | Tim Evers
> Eingetragen im Handelsregister Hamburg - HRB 81478
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html