[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XEN 4.3.0 WINDOWS HVM 3GB RAM ISSUE
> On Sun, 2013-11-03 at 20:56 +0200, NiX wrote: >> > On Tue, 2013-10-22 at 23:07 +0300, NiX wrote: >> >> Hello list! >> >> >> >> ---------------------------------------------------------------------------------------------------- >> >> The problem >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> Windows 7 64bit nor Windows 2008 R2 Enterprise Server 64bit is not >> >> starting with more than 3GB of RAM in HVM mode >> >> >> >> As a reference: >> >> >> >> Ubuntu 64-bit server is starting without any issue with 5GB of RAM on >> >> this >> >> server in HVM mode >> >> And all PV guest can use as much RAM as available when using 64bit >> >> linux. >> >> >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> System: >> >> > > CPU's: 2 x XEON X5450 >> >> > > Motherboard: Intel Server Board S5000PSLSASR >> >> > > http://ark.intel.com/products/46544/Intel-Server-Board-S5000PSLSASR >> >> >> >> > > RAM: 16GB DDR2 ECC >> >> > > Dom0 OS: Debian 7.0 64bit >> >> >> >> ---------------------------------------------------------------------------------------------------- >> >> >> >> xl create 10.100.12.10.cfg >> > >> > Does "xl -vvv create <the rest>" produce anything extra? >> > >> >> ---------------------------------------------------------------------------------------------------- >> >> VM config >> >> ---------------------------------------------------------------------------------------------------- >> > [...] >> >> shadow_memory=8 >> > >> > Is there a reason you are overriding this instead of accepting the >> > default? I notice your xl dmesg has mention of running out of shadow >> > RAM, which might be related. >> >> I remember reading that should help you to get a larger resolution when >> using VNC to access VPS console. > > I don't think so, shadow_memory is used as part of the memory > virtualisation subsystem (either shadow paging or HAP), it has nothing > to do with console resolution AFAIK. You might be thinking of the > videoram option? > I messed up those options, yes I was thinking of the videoram option. I'll also forward this information to xen-users because I asked there also help to this issue. >> >> > [...] >> >> (XEN) common.c:1598: d10 failed to allocate from shadow >> >> pool<G><2>memory.c:132:d0 Could not allocate order=9 extent: id=10 >> >> memflags=0 (2 of 4) >> >> (XEN) printk: 11634 messages suppressed. >> > >> >> (XEN) grant_table.c:350:d0 Bad flags (0) or dom (0). (expected dom 0) >> >> (XEN) common.c:1598: d11 failed to allocate from shadow >> >> pool<G><2>memory.c:132:d0 Could not allocate order=9 extent: id=11 >> >> memflags=0 (2 of 4) >> >> (XEN) grant_table.c:350:d0 Bad flags (0) or dom (0). (expected dom 0) >> > >> > This looks like the root cause of the failure which xl reported. I >> > wonder if this could be a dom0 kernel issue. What are you running >> there? >> > Some sort of custom kernel with the grsec patches perhaps? Can you try >> > without those to rule out an incompatiblity? >> >> I run there custom kernel 3.2.51-grsec but that have got nothing to do >> with the issue. I've tested it without custom kernel and/or grsec. >> >> I just commented out #shadow_memory=8 and I can now start both Win7 and >> R2/2008 server with more than 4GB of RAM. Thank you for catching this >> 'error'. > > Great. > >> >> > >> > I'm not at all sure why the type of guest would be related to anything >> > of that type though. A failure during domain build time like you are >> > seeing is too soon to even know what kind of guest it is going to be. >> > Could there be any options which differ between the configuration >> files >> > for your working and non-working guests? >> > >> > Ian. >> > >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@xxxxxxxxxxxxx >> > http://lists.xen.org/xen-devel >> > >> >> > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |