Archived/Xen API Project

From Xen
Revision as of 12:51, 28 March 2014 by Rcpavlicek (talk | contribs) (Reference)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Xen Management API Project

The Xen Management API is an interface for remotely configuring and controlling virtualised guests running on a Xen-enabled host.


This project is collaborating around a central document, titled "Xen Management API", presenting our ideas in terms of a data model, with an implied binding to XML-RPC calls. These XML-RPC calls can then be used (over one of a number of transports) to manage a Xen-based system.

The intention is to standardize both the data model and XML-RPC calls (one implying the other) and then the Xen project will guarantee that that wire protocol would be supported for the long term.

Behind that interface, we would then be free to improve Xend, and at the same time we give a solid foundation for third-party tools (in particular libvirt-based applications), GUIs, and so on. The API becomes effectively part of the "guarantees" of the Xen project.

The XML-RPC calls are the fixed standard, but we also have bindings to that XML-RPC for Python, C and Java. These are a thin translation from the host language's values and types onto the XML-RPC, so that they can be kept stable so that third-party applications can rely upon them in the long term. Cleverer facilities (such as Xen-CIM and libvirt) can then be built on top. These bindings are open-source, and included in the Xen distribution for all to use.

The Xen API document and the language bindings were released into the xen-unstable tree immediately after the Xen 3.0.3 release, are being stabilized there for release as a preview with Xen 3.0.4, and then be released officially with Xen 3.1.0.


We are currently discussing the new development of the open source Xen API implement. Initial Meeting for interested parties on May 15, 2008 at 4pm EST (1.888.371.8921 / Code 275279). Meeting minutes will be posted on this Wiki page and all additional items are welcome.

Notes for initial meeting: [1]

Meeting 1 Minutes and Action Items: [2]

Meeting 2 Questions Sent In: [3]

Meeting 2 Minutes and Action Items: [4]


List of Current Xen API 1.0 Functions that need completion or update:(PATH:tools\python\xen\xend)

    • host_set_logging
    • VM_get_VCPUs_max
    • VM_get_VCPUs_at_startup
    • VM_get_name_description
    • VM_get_user_version
    • VM_set_name_description
    • VM_set_user_version
    • VM_set_is_a_template
    • VM_get_crash_dumps
  • VIF configuration
    • We cannot configure 'model', 'accel', 'rate', 'ip' or 'script' through xenapi.
    • RFC:
      • Add "other_config" field to VM class
      • from XendConfig.device_add: if cfg_xenapi: if dev_type == 'vif': get these info from cfg_xenapi.other_config.
  • XenAPI C bindings
  • XenAPI Java bindings
  • XM client improvement

List of Features for future Xen API desired:

  • Requests from JoshWest <>:
    • Storage Repository custom (and pluggable) driver support:
      • Would be extremely beneficial to be able to plugin custom storage repositories on dom0's, to abstract handling of VDI creation/removal but still make it possible to manage within Xen.
  • Functionality within Storage Repository drivers to check/confirm a VDI's device/path exists on the Host.
    • Metrics for VDI's:
      • I/O Kbps (can be gathered via iostat command, part of sysstat package).
      • As VDI's are custom to the Storage Repository driver used, it may be wise to have the VDI metric gathering routine native to the Storage Repo driver, so all storage methods can have VDI metrics (all gathered by different means).
  • Additional metrics for VM's:
    • Memory usage within the VM (need to make hypercalls like xentop?)
  • Support for custom PIF devices, so they're recognized via the API -- right now only interfaces named peth0 are accepted.
    • Clarification on the "Task" class within the API; no documentation or examples of its usage or functionality beyond API reference.
    • Event notification upon VM migration. Event handler in API doesn't even state the VM's POWER_STATE has changed, nevermind that it was migrated.

Mailing Lists

Please join the xen-api mailing list if you are interested in this project.