Am 10.02.2012 11:36, schrieb Stefan Hajnoczi: > On Fri, Feb 10, 2012 at 10:35 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Fri, Feb 10, 2012 at 9:47 AM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: >>> Today i tried to create one VM with the option "-m 4000", and found it >>> failed with the following errors: >>> >>> Failed to allocate 4194304000 B: Cannot allocate memory >>> Aborted (core dumped) >> >> Did you run on a 32-bit host? > > BTW we shouldn't abort(3).
There's two slightly different scenarios to consider here: i) User specifies command line options that cannot possibly work. => Ideally, yeah, we should just provide an understandable error message and exit with error code. ii) Some tracing of mine indicates QEMU has a highly dynamic memory usage during runtime, be it due to network layer, block layer or whatever exactly. Any memory allocation of those may fail due to soft or hard limits, including pthread_create. => We should not abort because the previously running guest is gone and it's data may be incomplete or corrupted. Not to mention that libvirt shows an odd error message. Problem is that there is no distinction at this point, so if we remove the abort(3) for use case i) we loose it for debugging ii) as well. What would be cool is finding some way to avoid dynamic allocations after guest startup (i.e., preallocated memory pools) and dealing with running out of space there in a non-fatal way. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg