[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Fix pci passthru in xend interface used by libvirt [and 1 more messages]
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |