Re: [Xen-devel] An Introduction to the Xen-API Work

[Stefan Berger <stefanb@xxxxxxxxxx>]

Hello Ewan,

   something must have broken
while moving the API code into the xen-unstable repository. I can create
multiple Gentoo domains using xapi.py and xapi.domcfg.py, but cannot delete
any of  them.

   Stefan

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 11/04/2006
10:29:07 AM:

> 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 thatplatform.
> 
> 
> 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
torecord 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel