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 
> a
> management tool (engine-core in this case) apply a ballooning "profile"
> according to the administrator's wishes.  MOM itself is intended to provide 
> the
> mechanism for this while oVirt can provide the policies.  The policy handling 
> is
> 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.

Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to