On Sat, Oct 15, 2011 at 10:34:55PM +0200, Yaniv Kaul wrote:
> On 10/15/2011 10:19 PM, Dan Kenigsberg wrote:
>
> <SNIP>
> > I find it quite awkward for ovirt-engine to send code to MOM. It is not
> > like the
> > programmers of ovirt-engine are smarter than you and could devise a better
> > policy. It *is* important to have "ballooning profiles" attached to guests
> > (e.g.
> > "this VM is holy, do not balloon unless host is in deep manure") or hosts
> > ("keep
> > 100Mb free at all costs"). I think that defining the available profiles is
> > the
> > business of MOM - no one can do it better.
> >
> > Dan.
>
> I disagree, for one reason - the engine has an overall view of the
> system, not just of a single node.
> However, I haven't found yet where it can be advantage. I'm sure there
> are such cases, though.
> The knowledge of an operating system, its properties (to which user it
> belongs, its priority, is it related to another VM, ...) probably has
> some value.
> Y.
One example I might put forth is a policy that cooperates with node fencing. If
a user plans to fence a node (in order to perform a hardware upgrade or for some
other reason), we may want to push a different policy to that node while virtual
machines are migrated away from it.
Some may argue that this could be implemented in a permanent policy through
manipulation of simple variables. I don't tend to agree. The current policy is
pretty basic but as we add additional control points and dependencies, the
system will become more complex. It will become increasingly more difficult to
write a comprehensive policy that can expose enough simple 'control knobs' to
achieve the desired results for all of the potential use cases.
--
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
