WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Disallow setting maxmem to higher value than tot

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Disallow setting maxmem to higher value than total physical memory size
From: Michal Novotny <minovotn@xxxxxxxxxx>
Date: Wed, 01 Sep 2010 15:01:33 +0200
Cc: "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 01 Sep 2010 06:02:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1283345049.12544.9494.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C7E47B2.9010805@xxxxxxxxxx> <1283345049.12544.9494.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
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.
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? This is the check only for case that info['maxmem_kb'] > total_mem so if the value is not configured what value will be in this variable? If there would be a value of 0 (for example) it won't meet the condition at all.

What is the actual issue with setting a larger maxmem even for domain 0
that you are trying to resolve? Just that it will continue to attempt to
balloon up and never get there?

Like stated above, it's the incorrect value in xenstore so this xenstore value is not reliable without this patch since without this patch you can set the value of dom0/domU to, let's say, 10G, but this won't be correct since the value can be having just 8G of RAM. Therefore some scripts relaying on the xenstore information would get confused by maxmem settings since there will be a value of 10G but host would still be physically having just 8G so xend could not be trusted on that one so that's why I think this is worth fixing.

Michal

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel