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)
     - Set zram (compressed ram swap partition)
     - THP on|off
     - KSM speed control
     - Global host stat collection

  2. Guest controls
     - KSM per VM, on|off
     - THP per VM
     - Ballooning & auto ballooning
     - Future free page hinting
     - cgroup memory cap (per vm|group)
     - (I guess memory hot plug is outside of MOMs scope, but a bit
     - Guest&agent stat collection

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

Reply via email to