2009/5/20 Daniel P. Berrange <berrange@xxxxxxxxxx>: > On Tue, May 19, 2009 at 04:56:32PM +0200, Matthias Bolte wrote: >> Hello, >> >> I mentioned Hyper-V in my last mail. We are currently investigating >> Hyper-V support for libvirt. Basically there seem to be two options: >> >> - use the DCE/RPC library from the Samba project for Hyper-V's WMI protocol > > IIUC, WMI is just a name for Microsoft's impl of CIM/WBEM ? This is quite > a complex & verbose SPEC/API to use and doesn't lead to easy to understand > code. Yes, WMI is Microsofts implementation of CIM/WBEM, but they use DCOM as transport protocol instead of CIM-XML over HTTP. And that's the problem. The DCE/RPC library from the Samba project seem to be the only reasonable possibility to use DCOM from Linux. But we'll need to investigate this. > If this turns out to be the only viable way to write a Hyper-V driver, > then we'll have to accept it, but I think it'd be worth checking on the > viabilty of your 2nd option. > >> - write a Windows based Hyper-V driver and use it from a Windows based >> libvirt client only or port libvirtd to Windows > > What sort of API does Windows expose for managing Hyper-V directly on > the local host ? There's a potential risk of license compatability > questions, if their API license isn't GPL/LGPL compatible, though if > it is part of the core Windows OS APIs you can reasonably argue for > the 'system library exception' under the GPL. The Hyper-V API is WMI only, AFAIK there is no separate local API. WMI can be used remote and local. Its based on DCOM/COM. So the needed libraries would all be provided by Windows itself. I just read in the Wikipedia article about WMI, that Windows Server 2003 R2 will/should include a SOAP transport for WMI, we'll need to investigate this too. > Assuming there's a reasonable local API, then writing a driver should > not hit any serious portability problems - most of our internal utility > APIs are already cross-platform thanks to GNULIB, and the only core > 3rd party dependancy is libxml which already works on Win32. > > Getting the libvirtd daemon working will be more tricky, but I reckon > it would still be a tractable problem. We'd have to add a wrapper for > the pthread_create() API we use in the libvirtd daemon to our existing > wrappers for mutexes & condition variables. That wouldn't be too hard, > as there's plenty of example code, and libvirtd's thread requirements > are pretty simple really. The use of UNIX domain sockets obviously > wouldn't work, but having it use TCP listening on 127.0.0.1 by > default would be a viable alternative. GNULIB already provides us > with socket() and poll() event loop portability here. > > GNUTLS is already ported to Win32 so that's usable by the daemon. The > other auth stuff we use is SASL and we've not figured out a solution > for Win32 for that even for the libvirt remote client. This is a major > todo item even ignoring Hyper-V driver needs. > > PolicyKit / Avahi support in the libvirtd daemon can trivially be > turned off at compile time so can ignore that. That's good to hear. > The other interesting question though is how people typically deploy > Hyper-V hosts ? I've never used one myself, so have no idea of typical > deployment models. Specifically, does Windows ship with a pre-built > minimal restricted 'Dom0', or can the admistrator easily install > additional software in the 'dom0'. If Windows doesn't easily allow > people to install libvirt in the 'dom0', then the doing a local driver > wouldn't be useful & we'd have no choice but to use WMI. We're in an early phase of investigating Hyper-V and have no answers to this question yet. I just asked for advise in this early phase, because it's not so clear and simple how to handle Hyper-V compared to ESX. Regards, Matthias -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list