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

Reply via email to