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.
vdsm-devel mailing list