----- Original Message -----
> 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
> (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 ;-))
> 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.
> 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
> non-vdsm users.
Actually this was discussed on the last vdsm sync call and Adam suggested that
mom would have a mode where it is run from within vdsm (under vdsm context) so
that should not be a problem.
> vdsm-devel mailing list
vdsm-devel mailing list