Re: [PATCH] Disallow setting maxmem to higher value than total physical memory size

[Michal Novotny <minovotn@redhat.com>]

On 09/01/2010 04:18 PM, Michal Novotny wrote:
> On 09/01/2010 03:37 PM, Ian Campbell wrote:
>> On Wed, 2010-09-01 at 14:01 +0100, Michal Novotny wrote:
>>> On 09/01/2010 02:44 PM, Ian Campbell wrote:
>>>> On Wed, 2010-09-01 at 13:31 +0100, Michal Novotny wrote:
>>>>
>>>>> Hi,
>>>>> this is the patch to disallow changing the maxmem value to higher 
>>>>> value
>>>>> than total physical memory size since without this patch I was 
>>>>> able to
>>>>> set dom0 maxmem to higher (invalid) value which is not correct.
>>>>>
>>>> I think it is allowable for a domU though. Consider the scenario where
>>>> you have two hosts, one of which has more physical RAM than the other.
>>>>
>>> Yeah, that's right. This scenario has been taken into mind and in fact
>>> this patch shouldn't do any harm on domU but it was mainly made for 
>>> dom0
>>> since dom0 default maxmem value is being set to 16 GiB on x86_64 
>>> machine
>>> which is not correct since it allows setting up up to 16 GiB RAM to 
>>> dom0
>>> although we have available only 8 GiB for example. Issuing `xm mem-set
>>> 10240` is therefore possible but it shouldn't be so it's trying to
>>> reserve 10240. The main issue is that xenstore was having maxmem value
>>> of 10240 instead of maximum value possible, i.e. value of 8192 in my
>>> case. Since xenstore itself was having the incorrect information it was
>>> implemented for xenstore to provide valid information too.
>> I'm saying that I think your patch does cause have harm on a domU, I
>> don't see anything which limits its actions to just dom0. Can you
>> explain why a domU is not effected by this change.
>>
>> As far as I can tell the patch will prevent the creation of a domU which
>> has a maxmem larger than the current host is capable of providing. The
>> maxmem setting is the maximum memory is the amount of memory which the
>> domain _could_ be given. This is different from the amount it currently
>> actually has which can be different due to ballooning etc.
>>
>> A domain must be configured with this maxmem value at boot time because
>> it may need to dynamically size some of data structures (e.g. the frame
>> table) to allow it to balloon up at a later date.
> Oh, ok. It's not limited to dom0 nevertheless I don't see anything to 
> be causing anything bad in domU. Of course, I can limit this to dom0 
> but for domU you can be having e.g. this:
> 1)
> dom0: total memory = 8192
> domU: memory = 4096, maxmem = 8192 (xm mem-max domU 16384 fails)
> 2)
> and when you migrate to host B:
> dom0: total memory = 16384
> domU: memory = 4096, maxmem = 8192
> 3)
> so when migrating back to host A you'll have:
> dom0: total memory = 8192
> domU: memory = 4096, maxmem = 8192
>
> But I don't think this behaviour is that bad since if you won't be 
> having the patch applied you could be able to set max_mem to value of 
> 16G in step 1 and then in step 2 (8G host machine) you could be able 
> to issue `xm mem-max domU 10240` which is not valid on host B (as in 
> step 2) so we could prevent this by setting up domain maxmem to be 
> 8192 which is the maximum on host B.

Oh, sorry. I meant `xm mem-set domU 10240` there.

Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat