[libvirt] Hyper-V driver advise request

[Daniel P. Berrange]

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.

> We're currently not sure which way to go and if any of this will
> actually work. So, we just want to ask for advise.

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 :|