On Fri, Dec 02, 2011 at 03:08:24AM +0200, Dan Kenigsberg wrote: > On Thu, Dec 01, 2011 at 11:05:55AM +0200, Dor Laor wrote: > > On 11/29/2011 06:29 PM, Adam Litke wrote: > > > After discussing MOM / VDSM integration at length, two different > > > strategies have > > > emerged. I will call them Plan A and Plan B: > > > > > > Plan A: MOM integration at the OS/Packaging level > > > Plan B: MOM integration as a new VDSM thread > > > > I think a form of plan B is more appropriate: > > > > In general we can look at MOM vs VDSM just like micro kernel vs linux > > kernel approach. MOM can be independent project but then it will need to > > expose much more apis for VDSM and wise verse. > > > > For example, take live migration, there is no point of MOM balloon a > > guest while it is migrating. So either you ignore that which is bad or > > now need to listen to VDSM events on VM migration. > > > > Think about hot plug vcpu/pci-device to a VM - if before MOM used some > > SLA for the VM, now it will need to change to cope w/ the new resources, > > again more api/events for that. > > > > Another thing - all of the settings for per VM KSM/THP/Swap/Balloon - > > all will need to propagate from the vdsm api towards MOM. > > Indeed, disagreement is much more interesting! I think that the information > that Vdsm is expected to provide to momd is quite limitted and > slowly-changing. > We may be better off defining an API for Vdsm to notify momd of VM state > changes, than to entangle mom within Vdsm.
Yep. We will need to write a MOM GuestVDSM Collector in order to gather statistics from vdsm guests. This Collector could also fetch guest events using the vdsm API. -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
