On Tue, May 19, 2009 at 04:56:32PM +0200, Matthias Bolte wrote: 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. 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. 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. 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. 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. If you think it will be practical / feasible, and useful in the typical Hyper-V deployment models, then my preference would be for a local driver and port of libvirtd. But it may turn out that WMI is the only viable option in the real world. 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 :|