| 
         
xen-devel
RE: [Xen-devel] Strange (???) xl behavior for save, migrate and	migrate-
 
| 
To:  | 
Daniel Kiper <dkiper@xxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx> | 
 
| 
Subject:  | 
RE: [Xen-devel] Strange (???) xl behavior for save, migrate and	migrate-receive | 
 
| 
From:  | 
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> | 
 
| 
Date:  | 
Tue, 18 Oct 2011 10:58:08 -0700 (PDT) | 
 
| 
Cc:  | 
jeremy@xxxxxxxx, Ian, Konrad Wilk <konrad.wilk@xxxxxxxxxx>,	Jackson <Ian.Jackson@xxxxxxxxxxxxx>, v.tolstov@xxxxxxxxx,	xen-devel@xxxxxxxxxxxxxxxxxxx | 
 
| 
Delivery-date:  | 
Tue, 18 Oct 2011 11:02:31 -0700 | 
 
| 
Envelope-to:  | 
www-data@xxxxxxxxxxxxxxxxxxx | 
 
| 
In-reply-to:  | 
<20111018151630.GB9832@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> | 
 
| 
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:  | 
<20111017174036.GD29445@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>	<4ffd9c88-88d2-437f-9af1-f3f0149334d9@default>	<1318925941.16132.36.camel@xxxxxxxxxxxxxxxxxxxxxx	20111018151630.GB9832@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> | 
 
| 
Sender:  | 
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx | 
 
 
 
> From: Daniel Kiper [mailto:dkiper@xxxxxxxxxxxx]
> Subject: Re: [Xen-devel] Strange (???) xl behavior for save, migrate and 
> migrate-receive
> 
> On Tue, Oct 18, 2011 at 09:19:01AM +0100, Ian Campbell wrote:
> > On Mon, 2011-10-17 at 19:44 +0100, Dan Magenheimer wrote:
> > > In a recent internal discussion at Oracle, we were thinking about
> > > whether to enable hotplug functionality in a guest kernel and it
> > > raised some concerns about manageability.  I think right now
> > > the system administrator of the guest can arbitrarily increase
> > > memory size beyond maxmem...
> >
> > The memory limit for a guest is ultimately controlled by the host
> > administrator/toolstack. The in-guest admin cannot exceed that, even
> > using hotplug.
> 
> Correct.
> 
> > I think that limit is currently always set to the current balloon target.
> 
> Nope. It is set by maxmem option.
> 
> > AIUI Daniel's work only allows a guest admin to take advantage of new
> > memory above maxmem _after_ the host admin has provisioned that RAM to
> > the guest. IOW it only allows the guest to take advantage of new memory
> > given to it and does not allow the guest to acquire new memory of its
> > own accord.
> 
> Guest/host administartor could allocate for given guest no more memory than
> maxmem (its value could be changed by xl mem-max <domain> <new_size>) allows,
> regardless of mechanism (ballooning or memory hotplug) used for that 
> allocation.
> It means that memory hotplug does not pose any security threat in that area.
OK, thanks for the clarification, Daniel and Ian.
> > P.S. Also FYI, selfballooning is implemented in Oracle's kernel
> > so we should work to ensure that selfballooning and hotplug
> > work properly together.
> 
> I am happy to do that, however, I am very busy now.
> Could we postpone this 2-3 months ???
Sure, that's fine.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |   
 
 | 
    |