Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-10-04 at 17:54 +0100, Dan Magenheimer wrote:
> Scanning through the archived message I am under the impression
> that the focus is on a single server... i.e. "punt if actor is
> not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid
> stepping on other memory overcommit technologies.

xl is inherently a single system toolstack, and a simple ballooning
based actor would just be its default.

The design is not intended to require that a toolstack only provide a
single actor, or indeed that the actor is provided by the toolstack at
all.

It would be perfectly reasonable for xl to provide actors which work
well with tmem or paging or sharing or some complex combination and even
to select them by default when those technologies are enabled on the
host.

We also fully expect that other toolstacks will want to provide their
own actors which make use of the facilities of those toolstacks to do a
better job based on the additional stateetc (e.g. we expect xapi to want
to provide a squeezed based actor).

Lastly design is also intended to support "3rd party" actors which are
not part of any toolstack. e.g. actors which talk to your cloud
orchestration layer or with some central authority or which communicate
with other hosts etc is intended to be a possibility.

>   That makes it
> almost orthogonal, I think, to the problem I originally raised.
> 
> But a bigger concern is that its focus on a single machine ignores
> the "cloud", where Xen seems to hold an advantage.  In the cloud,
> the actor is "controlling" _many_ machines.  In the problem I
> originally raised, this actor (a centralized management console)
> is simply looking for a server that has sufficient memory to house
> a new domain, and it (or the automation/sysadmin running it) gets
> unhappy if (xl running on) the server says "yes there is enough
> memory" but then later says, "oops, I guess there wasn't enough
> after all".

Integrating some sort of "entry control" into the actor protocol seems
like a logical addition to me (assuming we didn't already include it, I
didn't go back and check), since the details of when to say yes or no
seem like they would very depend on the policies of that particular
actor and the technologies which it is using to implement them.

Ian.


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