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