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.

> Note that there is a problem in putting MOM alongside Vdsm since Vdsm is a bit
> egotistical in its access to libvirt, and denies libvirt write access from
> non-vdsm users.

This is a very addressable problem.  We can either use Dan's suggestion (add
SASL credentials for MOM), or we can enable MOM to run in module context so that
it will simply create some threads for itself in the VDSM daemon.

-- 
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

Reply via email to