----- 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: vdsm-devel@lists.fedorahosted.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 
policy?

>      - KSM speed control

Doesn't mom do this today?

>      - Global host stat collection

collectd?

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

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@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to