[libvirt] Hyper-V driver advise request

[Matthias Bolte]

2009/5/20 Daniel P. Berrange <berrange at redhat.com>:
> 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