From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GT4Nr-0005OD-7v for qemu-devel@nongnu.org; Thu, 28 Sep 2006 18:29:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GT4Np-0005O1-QC for qemu-devel@nongnu.org; Thu, 28 Sep 2006 18:29:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GT4Np-0005Ny-Km for qemu-devel@nongnu.org; Thu, 28 Sep 2006 18:29:33 -0400 Received: from [66.249.82.234] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GT4T0-0004BT-DA for qemu-devel@nongnu.org; Thu, 28 Sep 2006 18:34:54 -0400 Received: by wx-out-0506.google.com with SMTP id r21so930573wxc for ; Thu, 28 Sep 2006 15:29:32 -0700 (PDT) Message-ID: <23bcb8700609281529w639d4f6dx1c781b02bdc39c9f@mail.gmail.com> Date: Thu, 28 Sep 2006 18:29:32 -0400 From: "Bill C. Riemers" Sender: docbill@gmail.com Subject: Re: [Qemu-devel] RAM overcomittment In-Reply-To: <200609281145.21521.joakley@solutioninc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20925_3211046.1159482572524" References: <1ACF2542-5DEE-49B5-8177-5B958911B0F6@gmail.com> <200609272242.00637.paul@codesourcery.com> <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 ------=_Part_20925_3211046.1159482572524 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I would suggest just the opposite, under commit your ram. If your base operating system is Linux, you can create your swap partitions under a host linux tmpfs directory. You can then safely over commit the amount of tmpfs swap space. The guest linux system will expect he swap to be slow, so it won't use it for buffering disk IO or such. However, until you actually exhaust the amount of physical ram available the tmpfs swap will actually b= e very fast. Bill On 9/28/06, James Oakley wrote: > > On Wednesday 27 September 2006 6:59 pm, The MoonSeeker wrote: > > Le 27 sept. 06 =E0 23:41, Paul Brook a =E9crit : > > > 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 > *uses all available RAM*. > > Overselling RAM for Linux guests as a terrible idea. > > -- > James Oakley > Engineering - SolutionInc Ltd. > joakley@solutioninc.com > http://www.solutioninc.com > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + > This e-mail is CONFIDENTIAL and contains information intended only for th= e > person(s) named. Any other distribution, copying or disclosure is strictl= y > 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. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > ------=_Part_20925_3211046.1159482572524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I would suggest just the opposite, under  commit your ram.  If yo= ur base operating system is Linux, you can create your swap partitions unde= r a host linux tmpfs directory.  You can then safely over commit the a= mount of tmpfs swap space.  The guest linux system will expect he swap= to be slow, so it won't use it for buffering disk IO or such.  Howeve= r, until you actually exhaust the amount of physical ram available the tmpf= s swap will actually be very fast.

Bill


On 9/28/06, James Oakley <joakley@solutioninc.com> wrote:
On Wednesday 27 September 2006 6:59 pm, The MoonSeeker wrote:
> Le 27= sept. 06 =E0 23:41, Paul Brook a =E9crit :
> > 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 muc= h memory as you want.
> >
> > qemu is currently limits ea= ch guest to 2Gb ram. This is independent
> > of how
> > m= uch physical memory the host has.
> >
> > Note that modern OS (everything except DOS) gene= rally 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 fix= e to 200 MB but have guaranteed RAM of
> 20MB. With qemu I need to have 10 X 200MB for VM's + 128 MB host o= f
> RAM installed on the work station...
>
> I think we c= an 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 gues= ts. The Virtuozzo guys don't advertise the fact that Linux
*uses all ava= ilable RAM*.

Overselling RAM for Linux guests as a terrible idea.

--
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 st= rictly
prohibited. If you have received this e-mail in error, please not= ify me
immediately at 902 420 0077 or reply by e-mail to the sender and destro= y
the original communication.
Thank You.
+++++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++++++++++++++++


______________= _________________________________
Qemu-devel mailing list
Qem= u-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
<= /blockquote>

------=_Part_20925_3211046.1159482572524--