Jim Fehlig writes ("Re: [Xen-devel] [PATCH] Fix pci passthru in xend interface
used by libvirt [and 1 more messages]"):
> Is there a wiki, doc, roadmap, etc. that provides more details on the
> tool stack future? E.g. when can we anticipate the xend-based stack no
> longer being the default? Xen 4.1? Are there plans to completely
> remove xend and associated code from xen-unstable?
The plan at the moment is to switch to them as the default toolstack
in Xen 4.1. This assumes xl/libxl are stable enough and
feature-complete enough - but they're very close, if not there
already.
For new features we're already strongly encouraging people to provide
xl implementations.
xm/xend will be retained in the 4.1 release, but we don't expect to be
taking many if any new features into xm/xend after 4.1, and the
future after that point is uncertain.
> I've seen some "interesting" custom tools over the years and would like
> to better understand how these users might be affected by the tool stack
> changes. What, if any, compatibility will there be with these existing
> xend interfaces?
Good questions:
> direct use of xm tool
xl is intended to be a direct like-for-like replacement for xm.
The only feature we intentionally don't support is embedded python
code in domain config files.
> xenapi (xen.org version)
If you want something like xenapi, you're probably better off with the
XCP distribution, which includes an Open Source version of the actual
original XenAPI implementation, for which the xend version was
intended as a compatibility layer.
> xmlrpc
> sexpr-over-http
These are deprecated. No new applications should be written to these
interfaces.
> I think there have been statements about traditional python
> configuration files working with xl. I assume this means config files
> containing only assignment statements correct?
Yes. Ordinary config files which contain simple assignments
(including assignments of lists) to configuration variables are
supposed to continue to work.
> I've tried several simple python config files with xl and haven't
> noticed any problems, but looking for a more authoritative statement
> about libxl compatibility with tradition, ubiquitous python config
> files.
Right. I hope I've answered this question. The intent is that the
traditional and ubiquitous xm config files will continue to work.
> > So it would be worth thinking about changing libvirt to use libxl
> > instead.
>
> Yes, I thought about it while investigating this bug. I think some
> answers to my questions above will help prioritize this task.
If you would like any help with adapting libvirt to libxl please do
let me know.
It is likely that, since libvirt would be an early user of libxl, we
will find that there are things that libxl doesn't do right that make
it hard for users other than xl. It is also likely that there is code
currently in xl_cmdimpl.c (ie, xl) which should be moved out into the
utility library so that libvirt can share it.
We would very much like to see movement in this area before 4.1, so
that the version of libxl in 4.1 is the one which libvirt needs.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home