On Tue, Apr 10, 2007 at 06:01:23PM +0530, Premjith Rayaroth wrote: > Hi,
> With the introduction of Xen-API, will 'xm' command be deprecated? .
No, certainly not. xm is the human-usable interface into Xend, and as such
certainly will stay in use going forward. Think of xm as a CLI tool that uses
the Xen-API. > 1. Apart from Remote/RPC calls, does Xen API have more features than 'xm' ?
Sure. The biggest feature is that the Xen-API has been designed to be
extensible and supportable in the long term. It is the only interface that
will be guaranteed to remain compatible at the wire-level as we move forward.
xm has never been like that, has changed many times in the past, and will
change many times in the future too. In essence, xm is designed to be used by
humans, but the Xen-API is designed for scripts and GUIs.
Another notable feature of the Xen-API over xm is the ability to perform
long-running tasks asynchronously, and to register for and process events
Xen-API achieves these things by being more orthogonal in its feature design
than xm, and more detailed. Obviously, humans often need a simplified, more
aggregated view of the world, compared with that offered by Xen-API, and it's
xm that does this aggregation. > 2. If I compromise on the remote/RPC feature, can I still keep using
> 'xm' for future releases of Xen?
> 3. Will 'xm' command be deprecated or discouraged as a best practice for
> the current/later releases of Xen?
If you are using xm for scripting purposes, then there is no guarantee that
things will not break underneath you. You would be much better off with a
Python Xen-API script, for example, as this is less likely to break. You will
also find it easier to extend your script later to take advantage of new
xm will not be deprecated in the sense that it represents the human-readable
interface into Xend, but it's certainly not recommended to build tools against
it. Those who've already done so should start an orderly transition over to
the new API.
xen-api mailing list