Mailing List Archive: Xen-CIM, libvirt, and Xen tools stack

All,

Given the recent work by Ewan and company on a Xen Management API and C
binding, the Xen-CIM project must now decide which API to use - either
the C binding directly or libvirt. The Xen-CIM project planned to use
libvirt all along, but given the developments over the past few months
we must now decide whether to continue on this path or move directly to
the C binding.

I will start a list some pros and cons that we can expand and ultimately
use to determine the appropriate path moving forward.

Reasons to stay with libvirt:
- Xen-CIM providers would inherit libvirt's ability to work with
arbitrary virtualization technologies
- Related to above, libvirt could become a standard API for managing
various virtualization technologies
- When on box, libvirt can provide optimizations for satisfying a request

Reasons to use C binding directly
- libvirt must expose all of the functionality described in the
management API spec before the providers can make use of it
- libvirt introduces another layer of code, assuming it eventually uses
the C binding as well
- libvirt is not 'in tree' (I do not have a problem with this but have
heard it mentioned before so wanted to include it)

Regards,
Jim

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Tue, Aug 15, 2006 at 03:42:29PM -0600, Jim Fehlig wrote:
> All,
>
> Given the recent work by Ewan and company on a Xen Management API and C
> binding, the Xen-CIM project must now decide which API to use - either
> the C binding directly or libvirt. The Xen-CIM project planned to use
> libvirt all along, but given the developments over the past few months
> we must now decide whether to continue on this path or move directly to
> the C binding.
>
> I will start a list some pros and cons that we can expand and ultimately
> use to determine the appropriate path moving forward.
>
> Reasons to stay with libvirt:
> - Xen-CIM providers would inherit libvirt's ability to work with
> arbitrary virtualization technologies
> - Related to above, libvirt could become a standard API for managing
> various virtualization technologies
> - When on box, libvirt can provide optimizations for satisfying a request

Just add one other which may be important for people with existing Xen
deployments which need managing:

- Compatability with Xen 3.0.2 and 3.0.3 releases

> Reasons to use C binding directly
> - libvirt must expose all of the functionality described in the
> management API spec before the providers can make use of it
> - libvirt introduces another layer of code, assuming it eventually uses
> the C binding as well
> - libvirt is not 'in tree' (I do not have a problem with this but have
> heard it mentioned before so wanted to include it)

Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api