All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Oakley <joakley@solutioninc.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RAM overcomittment
Date: Thu, 28 Sep 2006 11:45:21 -0300	[thread overview]
Message-ID: <200609281145.21521.joakley@solutioninc.com> (raw)
In-Reply-To: <A132AD5E-984E-432A-BBC4-1D7EE4B34529@gmail.com>

On Wednesday 27 September 2006 6:59 pm, The MoonSeeker wrote:
> Le 27 sept. 06 à 23:41, Paul Brook a écrit :
> > 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 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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  parent reply	other threads:[~2006-09-28 15:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-27 21:31 [Qemu-devel] RAM overcomittment The MoonSeeker
2006-09-27 21:41 ` Paul Brook
2006-09-27 21:59   ` The MoonSeeker
2006-09-27 22:19     ` Paul Brook
2006-09-27 22:53       ` The MoonSeeker
2006-09-27 22:58         ` Paul Brook
2006-09-27 23:12           ` [Qemu-devel] PowerPC Decrementer Clock Rate Ely Soto
2006-09-27 22:36     ` [Qemu-devel] RAM overcomittment andrzej zaborowski
2006-09-28 14:45     ` James Oakley [this message]
2006-09-28 22:29       ` Bill C. Riemers
2006-09-27 21:57 ` James Olsen
2006-09-27 22:16   ` The MoonSeeker
2006-09-27 22:21     ` Paul Brook

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=200609281145.21521.joakley@solutioninc.com \
    --to=joakley@solutioninc.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.