Re: [Qemu-devel] default guest RAM size?

[Daniel P. Berrange]

On Tue, Mar 05, 2013 at 09:26:32AM +0400, Michael Tokarev wrote:
> For many years, qemu defaults to 128Mb of guest RAM size.
> Today, this is just too small, and many OSes fails to boot
> with this size, more, they fail to produce any reasonable
> messages either (eg, windows7 just crashes at startup).
> 
> Some distributions (eg ubuntu) had a local patch to increase
> this value, for years.

Out of interest, what do they change it too ?

> Maybe it's time to increase the default RAM size a bit?
> Make it arch-specific if needs to be ?

As with pretty much all QEMU hardware defaults, the default RAM
size is always going to be a tradeoff between compatibility and
optimization for specific use case. I can understand that the
current RAM setting is useless for pretty much all x86 currently
shipping "retail" operating systems (ie the ubuntu, fedora, windows,
etc of today), but that's not really the only thing to worry about
when invoking QEMU. People invoking QEMU manually have to care
about many other aspects of hardware configuration that are going
to be OS specific.

I think rather than asking the narrow question of whether we need
to increase the default RAM, we need to have a clear statement on
what target the default QEMU machine setup is aiming at.

If answer to that is that we're aiming to offer parity with current
state of the art desktop hardware specs, then clearly we should be
changing the RAM and other aspects over time to keep up. But it
could be that our aim is to just not change the default hardware
ever and explicitly state that this is a job for a layer above
QEMU to solve.

We've had similar requests periodically against libvirt to say
we should default to hardware model XYZ, or hardware config ABC.
In the end we've always pointed out that by changing the defaults
you never really solve the problem - you are just moving the
problem from one person to a different person. The concept of
virtual hardware defaults is just impossible to get right, since
this is fundamentally something that has a different answer for
every OS out there.

This is what motivated the creation of the libosinfo project. It aims
to provide a database of all the various OS specific metadata for use
by such higher level tools, and API to query this database. Included
in the metadata it maintains are the minimum, and recommended resource
settings for RAM, CPU count and disk storage for that OS, recommended
default hardware devices, location of ISO images / install trees, ISO
image signatures, release/eol dates, and much more besides.

So now when anyone askes for a change in libvirt defaults we just tell
them that the app using libvirt should be picking the OS specific
settings from libosinfo or a similar kind of source. So far only the
GNOME boxes app is using libosinfo, but I'm intending to make both
virt-manager and OpenStack use it too.

NB libosinfo has no dependency on libvirt at all - its only dep is on
GLib, so we can use GObject introspection to expose the library to
many different languages.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|