Re: a ton of kernel issues

[George Shuklin <george.shuklin@gmail.com>]

On 13.12.2011 17:17, David Vrabel wrote:
>>>> pv_ops is still have some issues with memory limits, but any
>>>> new kernel (3.0+) will boot normal and operates with very
>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>>> more major issues.
>>> what glitches should one expect with 3.0+, and having the choice,
>>> would it be better to go with 3.1 or even 3.2?
>> Right now I know about two of them:
>> When you set up memory for virtual machine using xenballon, value in
>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>> without that memory. Practically that means if you set up memory for
>> domain to 2GiB client will saw only 1.95GiB and so on.
> This really makes no practical difference.  The memory is "used" is
> either case and the different reporting is a side-effect of the change
> in how certain memory allocations are done.
Well... For us it make HUGE difference. We running cloud with very 
precise accounting of  fast automaric memory allocation for customer's 
domains and we account them for ... em... KiB*hr value, so if we account 
domains based on xc.get_domain_memkb value and customers saw difference 
between TotalMem and our values this will make them feel like we 
cheating. We not greedy and ready to 'cut' our mem_kb value to their 
TotalMem, but I hasn't found any formula for that (calculate TotalMem 
from static-max and dom_kb values) and I can't trust any data from 
customer's domains (except request for memory we accept, serve and 
happily take money for 'more memory').

It sounds ridiculous, but we avoiding pv_ops kernels usage due that 
little ~50Mb steal. We stuck with -xen kernels (forward porting from 
SUSE and native CentOS 2.6.18-xen). I don't know what we will do in the 
future, but right now PV-ops is not good...

>> The second issue is lack of support of 'pre-inflated balloon', means you
>> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
>> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
>> (up to memory-static-max limit).
> This should work if memory hotplug is enabled.
>
> It is also supported without memory hotplug but this requires that the
> tools supply a suitable memory map that covers the largest
> memory-static-max limit you wish to support.  I'm not sure if the tools
> can do this yet.
>
Well... I post few weeks ago about problems with memory hotplug - I see 
this message in dmesg:

[1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
[1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
failed: -17

I post about that: 
http://old-list-archives.xen.org/archives/html/xen-users/2011-11/msg00278.html