All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moritz Duge <md@artfiles.de>
To: kvm@vger.kernel.org
Subject: Re: Having trouble with ballooning
Date: Mon, 16 Aug 2010 17:17:12 +0200	[thread overview]
Message-ID: <4C695678.9070200@artfiles.de> (raw)
In-Reply-To: <4C5AA35C.8010502@artfiles.de>

Hi there again,
just wanted to ask, why I'm getting no answers? Everyone's busy?
Has this already been discussed (I wouldn't actually believe, if I see 
how Qemu behaves for example in scenario 1)?

If you'd like to have more details about the issue or anything else, 
please contact me!

Thanks!
Moritz Duge



05.08.2010 13:41 by Moritz Duge:
> 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"???
>
>
> 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.
>
>
> 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".
>
>
> Thanks for reading and thanks a lot, if there will be a solution for 
> this, specially for scenario two.
>
> Greetings
> Moritz Duge

  reply	other threads:[~2010-08-16 15:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05 11:41 Having trouble with ballooning Moritz Duge
2010-08-16 15:17 ` Moritz Duge [this message]
2010-08-23 18:16 ` Marcelo Tosatti
2010-08-24 12:50   ` Moritz Duge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C695678.9070200@artfiles.de \
    --to=md@artfiles.de \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.