On Wed, Oct 12, 2011 at 09:46:53AM -0500, Adam Litke wrote:
> On Tue, Oct 11, 2011 at 10:25:38PM +0200, Dan Kenigsberg wrote:
> > On Mon, Oct 10, 2011 at 04:39:55PM -0500, Adam Litke wrote:
> > > Hi all,
> > >
> > > http://www.ovirt.org/wiki/Project_Proposal_-_MOM
> > >
> > > The link above will take you to the oVirt draft proposal for including
> > > Memory
> > > Overcommitment Manager (MOM) as an oVirt sub-project. I wanted to give
> > > folks on
> > > this list a chance to discuss MOM and an integration strategy before I
> > > ask the
> > > oVirt board to evaluate the proposal. Please take a look if you can and
> > > provide
> > > your feedback. Thanks.
> > Thank you for this opportunity. It is nice to have the pop of MOM around
> > (sorry, couldn't resist).
> > All Vdsm currently has in this front is the ability to notify ksmtuned that
> > a
> > new VM has joined the frill or left it. I would love to have something
> > smarter
> > than ksmtuned's policy (which MOM's ksm.rules is quite similar ;-)) and
> > ballooning support which we completely lack.
> > However I have a concern or two. I must admit that MOM's dynamic policies,
> > and
> > policy declaration language seems excessive to me. I cannot think of a use
> > case
> > where a policy cannot be hard-coded in Python as a plugin for a MOM-like
> > daemon.
> > What is the motivation for writing the policy in a special-purpose
> > language? Is
> > Vdsm supposed to own MOM's policy and feed MOM with it? Disclaimer: I've
> > only
> > had few minutes' glimpse at MOM's code.
> We thought about using static python code to implement policies but felt that
> would simply be too limiting for what we wanted to achieve. While I think the
> default MOM ballooning policy is pretty good, it is certainly not optimal yet
> and might not even do what some users would want. The current policy tries to
> mitigate host memory pressure by ballooning guests. Guests with more free
> memory are ballooned more aggressively. The thinking is that we could permit
> management tool (engine-core in this case) apply a ballooning "profile"
> according to the administrator's wishes. MOM itself is intended to provide
> mechanism for this while oVirt can provide the policies. The policy handling
> not very complex and has been working well.
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.
vdsm-devel mailing list