----- Original Message -----
> On 11/23/2011 07:09 AM, Adam Litke wrote:
> > On Tue, Nov 22, 2011 at 04:53:33PM -0500, Andrew Cathrow wrote:
> >> ----- Original Message -----
> >>> From: "Adam Litke"<a...@us.ibm.com>
> >>> To: firstname.lastname@example.org
> >>> Sent: Tuesday, November 22, 2011 4:29:41 PM
> >>> Subject: MOM integration questions
> >>> Hi guys,
> >>> I've got MOM up and running as a vdsm thread but I've hit two
> >>> small
> >>> problems.
> >>> I'll bounce them around on the list to see if people have some
> >>> ideas.
> >>> 1.) Libvirt SASL authentication
> >>> I was able to easily modify MOM to connect to libvirt by
> >>> hardcoding
> >>> the vdsm
> >>> credentials. Obviously this is not an acceptable long-term
> >>> solution.
> >>> What is
> >>> the best way to share the vdsm libvirt password with MOM in a way
> >>> that does not
> >>> compromise security? Whatever method we choose should not
> >>> involve
> >>> vdsm-specific
> >>> changes to MOM. For starters I think I will just place the
> >>> username
> >>> and
> >>> password in the mom.conf file. We could make this file readable
> >>> only
> >>> by the
> >>> vdsm user. Thoughts?
> >> Is it safe just to read it from
> >> /etc/pki/vdsm/keys/libvirt_password
> >> What's the reason for not wanting VDSM specific changes in MOM, is
> >> this project is part of oVirt then we can always assume VDSM is
> >> present.
> > My initial integration strategy for MOM is to alter it such that
> > vdsm can
> > load the MOM logic as a python module and execute it in a new vdsmd
> > thread. I
> > believe the cleanest interface is possible when the interaction
> > between MOM and
> > vdsm is one way (ie. vdsm controls MOM). In this scenario, MOM
> > would provide
> > all of the APIs that vdsm needs to have the required level of
> > control but MOM
> > would not call back into VDSM. By doing this, MOM can remain
> > focused on its
> > specific role in the stack without being aware of idiosyncrasies in
> > vdsm. There
> > are two exceptions to this rule: Collectors and Controllers. VDSM
> > can be a data
> > source. In this case, we can write a vdsm Collector that knows how
> > to query
> > VDSM for host and guest statistics. VDSM can also be a 'tuning
> > mechanism'
> > against which we can write a Controller to execute certain
> > privileged
> > operations. What I am concerned about is the need to update
> > supervdsm with a
> > new command each time we want to tweak a new sysfs file.
> Maybe a bit prior to discussing the exact integration between MOM and
> vdsm, we can discuss the set of classes and verbs it should control?
> For instance we have 2 major classes (further away in the future):
> 1. Host controls
> - Set swap partitions (maybe per guest or guest groups)
What does this have to do with a policy rule engine? these are static
definitions (or at most configured once VM goes up/down, no tweaking required
while vm is running)
why define a swap partition per guest/group ?
> - Set zram (compressed ram swap partition)
Again, on host this would be static (according to #CPUs), what does the rule
engine have to do with it?
> - THP on|off
Isn't this on by default? iirc there is no reason we know of to disable it?
In any event, for it to be controlled by a policy engine, there should be a
> - KSM speed control
Doesn't mom do this today?
> - Global host stat collection
> 2. Guest controls
> - KSM per VM, on|off
> - THP per VM
Why not always on?
> - Ballooning & auto ballooning
> - Future free page hinting
> - cgroup memory cap (per vm|group)
I don't understand why this is not in the host section.
> - (I guess memory hot plug is outside of MOMs scope, but a bit
Assuming the guest is able to support this and the policy states that the VM is
allowed to reach a certain amount of memory, why not control this according to
guest memory usage and memory availability? i.e. why would you consider this
out of MOMs scope?
> - Guest&agent stat collection
You focused on memory only. What about cpu? network? storage?
> Will all be done by Mom? How about defining just a RFC interface and
> then try to hook into vdsm's api
> >>> 2.) Permissions
> >>> The first error I noticed was MOM failing to adjust KSM via
> >>> sysfs:
> >>> 2011-11-22 10:13:48,313 - mom.Controllers.KSM - WARNING - KSM:
> >>> Failed
> >>> to write
> >>> /sys/kernel/mm/ksm/run: Permission denied
> >>> MOM is used to running as root so that it can adjust these
> >>> settings.
> >>> I would
> >>> prefer not to complicate the MOM architecture by having a
> >>> separate
> >>> process that
> >>> receives instructions from the main MOM thread and then applies
> >>> the
> >>> requested
> >>> changes as root.
> >>> Another solution would be to allow MOM to run as a completely
> >>> separate daemon
> >>> (as it has been originally doing). In this scenario, vdsm would
> >>> reconfigure MOM
> >>> by replacing the default configuration file and policy. vdsm
> >>> could
> >>> then
> >>> interact with the running momd via the existing xmlrpc interface.
> >>> Thoughts on these issues?
> vdsm-devel mailing list
vdsm-devel mailing list