public inbox for kvm@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox