On Thu, Jan 08, 2009 at 01:11:27PM -0000, Gerhardus.Geldenhuis@xxxxxxxxxxxxxx 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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list