Re: [libvirt] Hyper-V driver advise request

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.

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.

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.