DV> The question really is is it a good interface ? In theory it DV> sounds like it could help us, but I wonder how that actually works DV> in practice. In practice, it's almost impossible to write a client that works with a given provider model (at more than a very basic level) without any a priori knowledge of the implementation. The intent is for this to be possible, but it never seems to follow through in the execution of a client. Some clients are better about it than others, but grow significantly in complexity because they have to do more discovery of the model. My initial feeling is that adding a CIM client to libvirt wouldn't achieve the desired "silver bullet" effect of providing support for multiple CIM-enabled platforms, so you'd end up writing different drivers for each anyway. You would be able to share some common CIM client code, but not the whole driver. There are some other potential gotchas here, too. Like, what happens if the CIM provider returns a job instead of completing an action right away? Most of the SVPC profiles allow the provider to delay any action indefinitely by returning a job object for you to monitor. That doesn't fit very well into the libvirt API semantics, IMHO :) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list