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