From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1GSi1O-0001kn-Ry
	for qemu-devel@nongnu.org; Wed, 27 Sep 2006 18:36:54 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1GSi1N-0001jn-BZ
	for qemu-devel@nongnu.org; Wed, 27 Sep 2006 18:36:54 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1GSi1N-0001jk-7V
	for qemu-devel@nongnu.org; Wed, 27 Sep 2006 18:36:53 -0400
Received: from [66.249.82.234] (helo=wx-out-0506.google.com)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1GSi6K-00015p-81
	for qemu-devel@nongnu.org; Wed, 27 Sep 2006 18:42:00 -0400
Received: by wx-out-0506.google.com with SMTP id r21so448231wxc
	for <qemu-devel@nongnu.org>; Wed, 27 Sep 2006 15:36:52 -0700 (PDT)
Message-ID: <fb249edb0609271536n6b7c74aena9a52723811c017d@mail.gmail.com>
Date: Thu, 28 Sep 2006 00:36:51 +0200
From: "andrzej zaborowski" <balrog@zabor.org>
Sender: balrogg@gmail.com
Subject: Re: [Qemu-devel] RAM overcomittment
In-Reply-To: <A132AD5E-984E-432A-BBC4-1D7EE4B34529@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1ACF2542-5DEE-49B5-8177-5B958911B0F6@gmail.com>
	<200609272242.00637.paul@codesourcery.com>
	<A132AD5E-984E-432A-BBC4-1D7EE4B34529@gmail.com>
Reply-To: balrogg@gmail.com, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hi,

On 27/09/06, The MoonSeeker <themoonseeker@gmail.com> wrote:
> Ok but some virtual solution like openVZ allow you run more VM than the
> memory installed. By example, with openVZ I can create 10 Virtual Machine
> who have a limite fixe to 200 MB but have guaranteed RAM of 20MB. With qemu
> I need to have 10 X 200MB for VM's + 128 MB host of RAM installed on the
> work station...
>
> I think we can Save ressource because in the most case, the VM's will never
> use the 200MB. I think it will be a nice if qemu implemented a tool that let
> use exceed this limitation.

How would you implement that?

>
> I can show you an application domain :
>
> For my diploma project, I have to create a network simulator but with these
> limitation I can't use qemu. Because if would like to simulate 20 workstions
> I need 20 X 128 MB = 2560 MB of RAM... + host RAM!!! But in the simulation,
> the VM's never will use all of ressource..

Then give the VMs only as much as they will use (note that VMs can
also have swap) or use host swap.

Regards,
-- 
balrog 2oo6