On Fri, Oct 17, 2008 at 10:42:25AM +0100, Daniel P. Berrange wrote: hi Atsushi, I got your question spinning on the back of my head since this morning, but it's really hard to come up with good answers, maybe peopel with more knowledge of CIM could give informations. The question really is is it a good interface ? In theory it sounds like it could help us, but I wonder how that actually works in practice. I agree that an abstraction layer doesn't sounds a good thing, *but* since there hasn't been that many volunteers to implement VMWare or Hyper-V, the fact that Hyper-V native would certainly have to be working locally on the Windows machine and be compiled with MSC [1], the fact that for VMWare we would have to do remote access with SOAP anyway for deployment issues, that all considered maybe a client CIM remote driver may not be that bad in comparison. Also having looked at the VMWare vix and SOAP APIs I'm not sure that CIM can really be that much worse (but I'm certainly biased). Atsushi do you know if by default VMWare ESX and Hyper-V allow CIM XML access, or if some 'additional' software need to be installed to get this to work ? Also if you have feedback about the quality of the client CIM APIs implemented (completeness, interoperability ...) that's good to know too, Daniel [1] there is a collection of horror stories for libxml2 compiled with a given toolchain and linked with library built differently on Windows, I would not raise hope for mixing compiler environments -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

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(a)us.ibm.com

On Mon, Oct 20, 2008 at 06:16:14PM +0900, Atsushi SAKAI wrote: Well as Dan Smith pointed out this may get really tedious, especially the asynchronous part of CIM processing. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/