All,
As you may have noticed, the Xen-API development tree has been merged into
xen-unstable. The work in this tree has been ongoing since June, and is now
ready for wider distribution. I'd like to take a few minutes to describe
these changes, and then I'll follow up this email with a more detailed design
document.
The Xen-API tree has been released to xen-unstable now, so that it can be
stabilised for release as part of Xen 3.0.4. The interfaces discussed below
are still open to change, and will only be frozen when Xen 3.0.4 is released.
The Xen-API work had a number of goals:
1. Support the Xen-CIM project in its development of CIM providers for
managing Xen-based hosts. DMTF's CIM is the accepted standard for the
monitoring and management of hetrogenous clusters, and the Xen-CIM team
are working to integrate Xen-based hosts into these environments through
the development of a CIM -> Xen bridge.
2. Encourage the development of third-party clients for managing Xen
directly. For enterprise-level hetrogeneous environments, the best
management interface to use is CIM, but for small, simple deployments,
direct lightweight management may be preferred. To this end, we wish
to support third parties in the production of clients, by providing
an interface that they can use.
3. Integrate the remote management of Xen systems, and make remote
management both easy to use and secure.
To this end, the major effort for the Xen-API project has been to provide a
interface into Xend that is stable and can be supported in the long term.
This will give a solid foundation for the CIM providers, and a guaranteed
interface for direct management tools.
This interface is XML-RPC based, with a data-model and message semantics
layered on top. The wire-protocol will be guaranteed for the long term,
ensuring that clients using it will be binary-compatible with all Xen releases
after Xen 3.0.4.
As well as fixing the wire protocol, we will be providing bindings written in
a number of languages, and making these available in-tree. tools/libxen
contains the new C bindings to this API, and the Python clients can get
up-and-running immediately with reflective bindings using xmlrpclib2.
The intention for the bindings is that they will be a thin layer on top of the
wire protocol and data model, with little in the way of moving parts. On top
of this, we expect libraries such as RedHat's libvirt to add the richer
functionality. This split allows the libraries in the Xen tree to be stable
and widely used, and allows third parties to innovate on top of that platform.
Lifecycle Changes
-----------------
To manage a VM properly over its whole lifetime, Xend needs to understand more
about VMs than it has traditionally done. Xend used to understand VMs only
when they were running, receiving configuration parameters for those VMs from
the outside, and removing the configuration details again as soon as the VM
shut down. This meant that external systems were needed in order to record VM
details over the long term, such as the xendomains script. In order to
properly manage VMs remotely, this has to be improved, with Xend becoming
responsible for tracking VM configuration even once the VM has been shut down.
To this end, there are some new xm commands:
o xm new - Introduces a new VM to Xend
o xm delete - Removes a specified VM
o xm start - Boot a named VM
o xm create - Does what it always did, which now makes it equivalent to
"xm new ; xm start"
o xm suspend - Save a VM to a location under Xend's management
o xm resume - Resume a VM from that same location
xm list will report non-running VMs, if you ask it to, as well as running
ones.
Authentication
--------------
Remote management needs proper authentication. At the moment, you must run xm
as root if you want to make any changes to the system, and that's the only
authentication we have. For Xen 3.0.4, Xend will be enhanced so that it is
able to authenticate users through PAM, giving administrators the power to
allow Xend operations to be performed, without giving away the root password.
What We've Got
--------------
o Many changes to Xend (xen-unstable.hg/tools/python/xen)
o New C bindings to the Xen-API (xen-unstable.hg/tools/libxen)
o Scripts for experimenting with the Xen-API, much of which will be rolled
into xm in time (xen-unstable.hg/tools/python/scripts)
o A document describing the Xen-API (xen-unstable.hg/docs/xen-api)
What We Need
------------
o Tests for the new xm commands, through xm-test.
o Lots of people trying the new API and the new C bindings, to see whether
they meet your needs.
o Implementation of the remaining API functions, in particular the
network-related ones, and those on the to-do list in the documentation.
o Documentation improvements.
o A Xend bug-squash.
o Lots of feedback!
Thanks, and have fun,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
As you may have noticed, the Xen-API development tree has been merged into
xen-unstable. The work in this tree has been ongoing since June, and is now
ready for wider distribution. I'd like to take a few minutes to describe
these changes, and then I'll follow up this email with a more detailed design
document.
The Xen-API tree has been released to xen-unstable now, so that it can be
stabilised for release as part of Xen 3.0.4. The interfaces discussed below
are still open to change, and will only be frozen when Xen 3.0.4 is released.
The Xen-API work had a number of goals:
1. Support the Xen-CIM project in its development of CIM providers for
managing Xen-based hosts. DMTF's CIM is the accepted standard for the
monitoring and management of hetrogenous clusters, and the Xen-CIM team
are working to integrate Xen-based hosts into these environments through
the development of a CIM -> Xen bridge.
2. Encourage the development of third-party clients for managing Xen
directly. For enterprise-level hetrogeneous environments, the best
management interface to use is CIM, but for small, simple deployments,
direct lightweight management may be preferred. To this end, we wish
to support third parties in the production of clients, by providing
an interface that they can use.
3. Integrate the remote management of Xen systems, and make remote
management both easy to use and secure.
To this end, the major effort for the Xen-API project has been to provide a
interface into Xend that is stable and can be supported in the long term.
This will give a solid foundation for the CIM providers, and a guaranteed
interface for direct management tools.
This interface is XML-RPC based, with a data-model and message semantics
layered on top. The wire-protocol will be guaranteed for the long term,
ensuring that clients using it will be binary-compatible with all Xen releases
after Xen 3.0.4.
As well as fixing the wire protocol, we will be providing bindings written in
a number of languages, and making these available in-tree. tools/libxen
contains the new C bindings to this API, and the Python clients can get
up-and-running immediately with reflective bindings using xmlrpclib2.
The intention for the bindings is that they will be a thin layer on top of the
wire protocol and data model, with little in the way of moving parts. On top
of this, we expect libraries such as RedHat's libvirt to add the richer
functionality. This split allows the libraries in the Xen tree to be stable
and widely used, and allows third parties to innovate on top of that platform.
Lifecycle Changes
-----------------
To manage a VM properly over its whole lifetime, Xend needs to understand more
about VMs than it has traditionally done. Xend used to understand VMs only
when they were running, receiving configuration parameters for those VMs from
the outside, and removing the configuration details again as soon as the VM
shut down. This meant that external systems were needed in order to record VM
details over the long term, such as the xendomains script. In order to
properly manage VMs remotely, this has to be improved, with Xend becoming
responsible for tracking VM configuration even once the VM has been shut down.
To this end, there are some new xm commands:
o xm new - Introduces a new VM to Xend
o xm delete - Removes a specified VM
o xm start - Boot a named VM
o xm create - Does what it always did, which now makes it equivalent to
"xm new ; xm start"
o xm suspend - Save a VM to a location under Xend's management
o xm resume - Resume a VM from that same location
xm list will report non-running VMs, if you ask it to, as well as running
ones.
Authentication
--------------
Remote management needs proper authentication. At the moment, you must run xm
as root if you want to make any changes to the system, and that's the only
authentication we have. For Xen 3.0.4, Xend will be enhanced so that it is
able to authenticate users through PAM, giving administrators the power to
allow Xend operations to be performed, without giving away the root password.
What We've Got
--------------
o Many changes to Xend (xen-unstable.hg/tools/python/xen)
o New C bindings to the Xen-API (xen-unstable.hg/tools/libxen)
o Scripts for experimenting with the Xen-API, much of which will be rolled
into xm in time (xen-unstable.hg/tools/python/scripts)
o A document describing the Xen-API (xen-unstable.hg/docs/xen-api)
What We Need
------------
o Tests for the new xm commands, through xm-test.
o Lots of people trying the new API and the new C bindings, to see whether
they meet your needs.
o Implementation of the remaining API functions, in particular the
network-related ones, and those on the to-do list in the documentation.
o Documentation improvements.
o A Xend bug-squash.
o Lots of feedback!
Thanks, and have fun,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
