Re: [Xen-devel] 3.0.5-rc3: Creating HVM guest fails with: Cannot allocate memory

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Mon, Apr 30, 2007 at 02:59:08PM -0400, Charles Coffing wrote:
> On Fri, Apr 27, 2007 at  7:26 AM, "Daniel P. Berrange" <berrange@xxxxxxxxxx> 
> wrote: 
> > On Fri, Apr 27, 2007 at 07:53:24AM +0100, Keir Fraser wrote:
> >> On 27/4/07 00:12, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
> >> 
> >> > The _constructDomain call is failing in xc.domain_create() - the code 
> >> > which
> >> > deals with ballooning down Domain-0 is not even run yet - that lives in
> >> > the _initDomain method. So HVM domain creation is failing before XenD has
> >> > even had a chance to do ballooning. If I manually use 'xm mem-set' to
> >> > balloon down Domain-0 ahead of time, everything works just fine.
> >> > 
> >> > I'm at a lose to figure out how to solve this without major re-arranging
> >> > of the order of _constructDomain & _initDomain work. Perhaps someone can
> >> > figure out an easier fix ?
> >> 
> >> I don't think domain_create() allocates very many pages, although it's
> >> possible it's making a default allocation of shadow memory. Assuming not, 
> >> it
> >> may be sufficient to make auto-balloon leave a bit of slack memory rather
> >> than try to account for all available memory down to the last page. A few
> >> pages might turn out to suffice. Does this problem occur with the very 
> >> first
> >> domain you try to create after booting the machine?
> > 
> > It seems to occurr with any HVM guest I try to create, unless there was 
> > already
> > some free mem (from starting & stopping a previous dom). I'm testing with 
> > this
> > very simple hack which seems to make it work - just ensure the balloon 
> > driver
> > frees a 10 MB chunk right at the start. Hardcoding is fine because when we
> > later get to the _initDomain() method we'll definitely be freeing up much
> > more than 10 MB for the HVM guests's actual mem requirements.
> 
> 
> Keir,
> 
> The problem Daniel fixed for fully virtual affects paravirtual, also.
> 
> We have received bug reports from ISVs of this problem in both the PV 
> and FV cases.  I traced code paths and discovered that FV attempts to 
> allocate the most memory during the initial domain creation; 64-bit PV 
> allocates the next most; 32-bit PV allocates the least.  So failures 
> for PV are less common, but not impossible.

Indeed - in testing on 64-bit PV over the weekend I saw perhaps 1 in 5
PV creation attempts fail with the not enough memory bug. So it does look
like the patch needs to be de-indented to fix PV too.

Regards,
Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel