[libvirt] RE: Libvirt - Xen Enterprise - Koan

[Daniel P. Berrange]

On Thu, Jan 08, 2009 at 01:11:27PM -0000, Gerhardus.Geldenhuis at gta-travel.com wrote:
> One more response:
> 
> I have just had this response from Citrix XS engineering in the US:
> 
> What's actually happened is the open-source Xen toolstack has fallen
> behind the Xen-API work, because no-one's putting anything into OSS
> at that level in the stack now (possibly with the exception of Red 
> Hat).

Sad but true - there's basically no active development on the open source
Xen userspace anymore - watching xen-devel the only active work is on the
hypervisor itself, and the upstream Linux kernel merge.

> In general, libvirt is basically a "lowest common denominator" library
> -- it will let you talk to multiple virtualization platforms with the
> same API.  If you want to do that, great, but the downside is always 
> that you lose functionality on the way.

Just to reassure people this is *not* true.  libvirt does NOT force
you to the 'lowest common denominator'. Our goal is to provide a 
consistent representation of configuration & a consistent API across
all hypervisors. We are more than happy to implement features that
are only present in particular hypervisors - the only point is to 
make sure they have a generic representation. This is the same goal
of the DMTF/CIM virtualization schema too. Neither is forcing you to
the lowest common denominator, merely a common representation.

> If the customer wants to use this Red Hat product, then writing 
> a libvirt-Citrix driver would be fine (and they are free to 
> open-source it too).

We would welcome & support anyone wishing to implement a new driver for
libvirt that can talk to the XenEnterprise API / SDK. Writing new drivers
for libvirt is much easier than it usde to be, since we have lots of 
generic infrastructure for handling XML formatting/parsing. There is no
requirement that you implement all the public APIs at once - its is 
perfectly feasible to only write a small subset of public libvirt APIs
in a new driver. For the purposes of the original question in thsi 
thread - Koan support - there would be few APIs required - ability to
list VMs, get host information / capabilities, and create new VMs. 

> On the other hand, if they're starting more or less from scratch 
> (and the version number "0.3" suggests that), then you're going 
> to get a much tighter integration if you use our SDKs directly, 
> and the result will be significantly better."

And nicely locked into the Xen specific API, making it very hard
for you to switch hypevisor vendors in the future. Of course that
is entirely what proprietry software vendors in general like :-)

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