On Fri, Oct 17, 2008 at 04:06:12PM +0200, Daniel Veillard wrote: > On Fri, Oct 17, 2008 at 10:42:25AM +0100, Daniel P. Berrange wrote: > > > As a CIM Provider, libvirt-cim is going on. > > > But for CIM Client, Is not going on. > > > > > > Is there any reason for not supporting CIM on libvirt driver layer? > > > I am thinking about cim-xml driver (like remote driver) in libvirt. > > > > It is certainly a possibility, but personally I'd prefer native drivers > > for each hypervisor - there is only VMWare & Hyper-V left that are the > > main players with no driver support. Having an abstraction layer like > > libvirt run over an abstraction layer like CIM, in turn over the native > > layer will make quite a complex system to debug & be inherantly less > > efficient than taking to the native APIs. So although it'd probably > > be more work to write a separate VMWare & Hyper-V driver, I think that > > it'd result in better drivers for each in the long term. > > 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). I agree there's not really much difference in complexity of CIM vs native VMWare APIs. My concern is primarily around the fact that we're stacking abstraction layers here. There is never a 1-to-1 mapping between semantics of each API, so CIM will be bending VMWare semantics to suit the CIM model. libvirt would then be bending the CIM semantics to suit the libvirt model. While things may appear to work normally, this tends to create all sorts of problems in the edge cases / fine details which are just impossible to resolve because CIM could be hiding some critical piece of information that VMWare could provide us. A libvirt impl directly ontop of VMware would have full access to all the information the VMWare API has, so could provide more reliable/predictable driver semantics. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list