[libvirt] Question about supporting other hypervisor
Hello, I have a simple question raised yesterday. CIM(Common Information Model) is a kind of good I/F (to support VMware, Hyper-V and other platform). 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. Ref. http://www.dmtf.org/standards/wbem http://en.wikipedia.org/wiki/Web-Based_Enterprise_Management Thanks Atsushi SAKAI
On Fri, Oct 17, 2008 at 09:38:35AM +0900, Atsushi SAKAI wrote:
Hello,
I have a simple question raised yesterday.
CIM(Common Information Model) is a kind of good I/F (to support VMware, Hyper-V and other platform).
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. 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 :|
On Fri, Oct 17, 2008 at 10:42:25AM +0100, Daniel P. Berrange wrote:
On Fri, Oct 17, 2008 at 09:38:35AM +0900, Atsushi SAKAI wrote:
Hello,
hi Atsushi,
I have a simple question raised yesterday.
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.
CIM(Common Information Model) is a kind of good I/F (to support VMware, Hyper-V and other platform).
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.
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). 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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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 :|
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@us.ibm.com
Hi, Daniel and all Thank you for various comments. These comments are very helpful for me. Daniel Veillard <veillard@redhat.com> wrote:
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,
For VMware, there has CIM tool. http://www.vmware.com/download/sdk/ For Hyper-V, there is a WMI. http://msdn.microsoft.com/en-us/library/aa490398.aspx By the way, I am not sure the quality of these CIM I/F implementation. But If there are have a possiblity, I will consider to check it. Thanks Atsushi SAKAI
On Mon, Oct 20, 2008 at 06:16:14PM +0900, Atsushi SAKAI wrote:
Hi, Daniel and all
Thank you for various comments. These comments are very helpful for me.
Daniel Veillard <veillard@redhat.com> wrote:
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,
For VMware, there has CIM tool. http://www.vmware.com/download/sdk/
For Hyper-V, there is a WMI. http://msdn.microsoft.com/en-us/library/aa490398.aspx
By the way, I am not sure the quality of these CIM I/F implementation. But If there are have a possiblity, I will consider to check it.
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Hi, Daniel I am looking around the wbemexec code on openpegasus. and count its code size.(seems small than I expected) Then I raised the question. Of course, Dan Smith's suggestion is very helpful advice. Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Mon, Oct 20, 2008 at 06:16:14PM +0900, Atsushi SAKAI wrote:
Hi, Daniel and all
Thank you for various comments. These comments are very helpful for me.
Daniel Veillard <veillard@redhat.com> wrote:
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,
For VMware, there has CIM tool. http://www.vmware.com/download/sdk/
For Hyper-V, there is a WMI. http://msdn.microsoft.com/en-us/library/aa490398.aspx
By the way, I am not sure the quality of these CIM I/F implementation. But If there are have a possiblity, I will consider to check it.
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (4)
-
Atsushi SAKAI -
Dan Smith -
Daniel P. Berrange -
Daniel Veillard