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"agl@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?