From mboxrd@z Thu Jan 1 00:00:00 1970 From: Moritz Duge Subject: Having trouble with ballooning Date: Thu, 05 Aug 2010 13:41:16 +0200 Message-ID: <4C5AA35C.8010502@artfiles.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE To: kvm@vger.kernel.org Return-path: Received: from mailout.artfiles.de ([80.252.97.80]:43202 "EHLO mailout.artfiles.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759160Ab0HEMGw (ORCPT ); Thu, 5 Aug 2010 08:06:52 -0400 Received: from [80.252.98.91] auth=md@artfiles.de by mailout.artfiles.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) id 1Ogyp2-0004T7-6T for kvm@vger.kernel.org; Thu, 05 Aug 2010 13:41:16 +0200 Sender: kvm-owner@vger.kernel.org List-ID: Hi, I had some trouble while using the ballooning feature of KVM (using=20 Ubuntu 10.04 with standard software versions). The first scenario: 1. Having a guest started by this command: qemu -enable-kvm -m 768=20 -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= =20 Qemu monitor. Qemu will report, the guest uses 256mb of memory now. The= =20 guest is reporting the same (using "free" for example). 3. Entering "change ide1-cd0 linux_2.6.18.iso" to change the guests=20 CD-ROM to another image, containing a Linux kernel without ballooning=20 driver. 4. Rebooting the guest. 5. After booting the 2.6.18-OS, it will report it has 768mb memory=20 (using "free). But Qemu monitor will still tell 256, when entering "inf= o=20 memory". I know why this happens. But is this a good behaviour? Shouldn't Qemu=20 tell something like "maybe 256, but there is no more balloon driver in=20 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=20 additional 512mb of memory (768 - 256)!!! I think this shouldn't happen= =20 or at least there should be an option to allow or deny this. Or at leas= t=20 least least this should be printed in big letters in the man-pages or=20 somewhere else where everyone will read it! Because before I experienced this, I assumed I can be sure the guest=20 can't get back the memory which was freed using ballooning. So if I use= =20 the memory freed by ballooning for some other qemu-instances and the=20 first one starts to use those memory again, all Qemu instances will=20 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=20 assigned by ballooning. And if the guest tries to use more memory (mayb= e=20 because it just unloaded the ballooning driver) the guest should crash,= =20 but the host shouldn't get in any trouble!!! This can be really annoying. I think a very common use-case for=20 virtualization is, to run untrusted software or unsecure webservices in= =20 a vm, so the bad software can't do anything to the host or other VMs on= =20 the host. But when using ballooning, the bad software can! It's no=20 "remote code execution", but the guest can consume a lot of memory and=20 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.= =20 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 wil= l=20 wait until the guest loads a ballooning driver. Is this a good=20 behaviour? Shouldn't there be at least a switch in the qemu monitor for= =20 the command "balloon". So if I use the switch when changing the memory=20 (e.g. "balloon -h 256"), qemu won't try to change the memory later and=20 it will tell me "error: no ballooning driver found". Thanks for reading and thanks a lot, if there will be a solution for=20 this, specially for scenario two. Greetings Moritz Duge --=20 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=E4ftsf=FChrer: Carsten Bals | Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478