From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GSyDQ-0003EA-6c for qemu-devel@nongnu.org; Thu, 28 Sep 2006 11:54:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GSyDP-0003Dy-Fb for qemu-devel@nongnu.org; Thu, 28 Sep 2006 11:54:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GSyDP-0003Dv-D2 for qemu-devel@nongnu.org; Thu, 28 Sep 2006 11:54:23 -0400 Received: from [65.110.18.31] (helo=elseed.funktronics.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GSyIW-0000Qy-5l for qemu-devel@nongnu.org; Thu, 28 Sep 2006 11:59:40 -0400 Received: from localhost (localhost [127.0.0.1]) by elseed.funktronics.ca (Postfix) with ESMTP id 54CDB10A97 for ; Thu, 28 Sep 2006 12:55:05 -0300 (ADT) Received: from elseed.funktronics.ca ([127.0.0.1]) by localhost (elseed.funktronics.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26761-05-4 for ; Thu, 28 Sep 2006 12:52:23 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by elseed.funktronics.ca (Postfix) with ESMTP id C72AC29A5B for ; Thu, 28 Sep 2006 11:46:08 -0300 (ADT) From: James Oakley Subject: Re: [Qemu-devel] RAM overcomittment Date: Thu, 28 Sep 2006 11:45:21 -0300 References: <1ACF2542-5DEE-49B5-8177-5B958911B0F6@gmail.com> <200609272242.00637.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200609281145.21521.joakley@solutioninc.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wednesday 27 September 2006 6:59 pm, The MoonSeeker wrote: > Le 27 sept. 06 =C3=A0 23:41, Paul Brook a =C3=A9crit : > > qemu is just like any other application. It is only limited by how > > much > > virtual memory your OS can provide. ie. if you have sufficient swap > > you can > > have as many qemu instances using as much memory as you want. > > > > qemu is currently limits each guest to 2Gb ram. This is independent > > of how > > much physical memory the host has. > > > > Note that modern OS (everything except DOS) generally use all > > available ram. > > Telling qemu to use more memory than you have physical ram is > > liable to cause > > heavy swapping. > > 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. Only Windows guests. The Virtuozzo guys don't advertise the fact that Linux= =20 *uses all available RAM*. Overselling RAM for Linux guests as a terrible idea. =2D-=20 James Oakley Engineering - SolutionInc Ltd. joakley@solutioninc.com http://www.solutioninc.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This e-mail is CONFIDENTIAL and contains information intended only for the person(s) named. Any other distribution, copying or disclosure is strictly prohibited. If you have received this e-mail in error, please notify me immediately at 902 420 0077 or reply by e-mail to the sender and destroy the original communication. Thank You. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++