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. Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
