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

[Michal Novotny <minovotn@redhat.com>]

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.

>
> Which xenstore node are you talking about?
>
>
>    

Oh, I confused xenstore and `xm list -l` output there. Sorry for that. I 
also tried to trigger the long listing using xl (using xl list -l) but I 
was having no luck to do so. The maxmem value is not available in 
xenstore but for `xm list -l` the value is there, you can try running:

`xm list -l | grep maxmem`

and before my patch applied you could see (maxmem 16777215) there. With 
my patch applied the correct value will be in this SXPR node.

I tried following for xl utility:

# xl list 0
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0  6958     4     
r-----      74.2
# xl list 0 -l
Usage: xl [-v] list [options] [Domain]


List information about all/some domains.

Options:

-l, --long              Output all VM details
-v, --verbose           Prints out UUIDs
# xl list -l 0
#

so obviously there's no option to get the long domain listing using the 
libxl but it's useful to parse domain information (e.g. using shell 
scripts) that you can get using e.g .`xm list 0 -l` command.

>>> You may which to boot a domain on the smaller host, (i.e. booting
>>> ballooned with a current_pages suitable for the small host) and then
>>> migrate it to the large machine where you then want to be able to
>>> balloon to a value larger than was even possible on the previous
>>> machine.
>>>
>>> If maxmem is not configured to the largest amount you consider you might
>>> want to give the domain then this scenario fails but it should work.
>>>
>>>        
>> Well, if maxmem is not configured for PV domain you mean?
>>      
> Sorry, I meant "If maxmem is not able to be configured to a value larger
> than the physical memory on the current host...".
>    

I see what you mean but I guess I already replied above. If we preserve 
the possibility to setup maxmem to higher value than dom0 physical 
memory is then `xm mem-max domU HigherValueThanPhysMem` will be possible 
to be issued which would lead to setup the invalid value in `xm list -l` 
output.

Or should I just ignore the possibility domU maxmem could be set to 
higher value than host machine could provide and should I limit my check 
to dom0 only?

Michal

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