[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] Xen-CIM, libvirt, and Xen tools stack


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)


xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.