Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature

[Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>]

On 11/05/2012 05:24 PM, Ian Campbell wrote:
> On Mon, 2012-11-05 at 14:54 +0000, Dan Magenheimer wrote:
>>> On Mon, 2012-11-05 at 00:23 +0000, Dan Magenheimer wrote:
>>>> There is no "free up enough memory on that host". Tmem doesn't start
>>>> ballooning out enough memory to start the VM... the guests are
>>>> responsible for doing the ballooning and it is _already done_.  The
>>>> machine either has sufficient free+freeable memory or it does not;
>>> How does one go about deciding which host in a multi thousand host
>>> deployment to try the claim hypercall on?
> I guess I don't see how your proposed claim hypercall is useful if you
> can't decide which machine you should call it on, whether it's 10s, 100s
> or 1000s of hosts. Surely you aren't suggesting that the toolstack try
> it on all (or even a subset) of them and see which sticks?
>
> By ignoring this part of the problem I think you are ignoring one of the
> most important bits of the story, without which it is very hard to make
> a useful and informed determination about the validity of the use cases
> you are describing for the new call.
Planned implement:

1. Every Server (dom0) sends memory statistics to Manager every 20 seconds
(tunable).
2. At one time, Manager selects a Server to run VM based on the snapshot of
Server memory. Selected server should have: enough free memory for the VM or
have free + freeable memory > VM memory.

Two ways to handle failures:

1. Try start_vm on the first selected Server. If failed, try the second one.

2. Try reserve memory on the first Server. If failed, try the second one. If
success, start_vm on the Server.

>From high level, Dan's proposal could help with 2). If memory allocation is 
>fast
enough (VM start failed/success very fast), then 1) is preferred.

Thanks,

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel