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.

Using either Plan A or Plan B MOM will need to support data collection from vdsm
and controlling/tuning via vdsm.  The principle difference is whether MOM is
required to interact with vdsm using a stable, external API (Plan B) or if we
allow it to tightly couple with vdsm and call internal functions (Plan A).
We all seem to agree that a public vdsm API should be created.  MOM can be the
perfect early-adopter.

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

These are interesting cases and tie into the discussion about a VDSM public API.
I can say with certainty that ISV applications would care about VM migration and
device hotplug events.  If these are made a part of the external API then MOM
can easily listen for them and react appropriately.  Yes, this will force us to
think carefully about which APIs to expose but in the end that is a good thing.

> Another thing - all of the settings for per VM KSM/THP/Swap/Balloon
> - all will need to propagate from the vdsm api towards MOM.

Currently MOM does not control individual guest OS tunables, but if it gains
that ability, it will be a part of the policy.  MOM already provides an API for
dynamically replacing the policy.

> I can go on this way.
> VDSM is not libvirt, it has policies today, there is no need to
> split it up into two or more.
> For completeness, I do think that there is a place for MOM like
> functionality within the OS. But I think for the best of ovirt
> project goals, it would be the most efficient to host all in VDSM
> and keep our actions VM specific.
> Thanks,
> Dor
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

vdsm-devel mailing list

Reply via email to