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 :|
