Re: XEN 4.3.0 WINDOWS HVM 3GB RAM ISSUE

["NiX" <nix@myproxylists.com>]

> 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@lists.xen.org
>> > http://lists.xen.org/xen-devel
>> >
>>
>>
>
>
>