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.