Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA passthough still not working)

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 25 Jan 2012, Florian Heigl wrote:
> > This was announced in the Xen 4.1 release notes[1] and the upgrade
> > guide[2]. In Xen 4.2 we have ended up formally deprecating xend rather
> > than removing it but you should expect that xend will be removed in a
> > future release of Xen and begin planning your transition to xl (or one
> > of the other alternative toolstacks), testing the features which matter
> > to you and reporting bugs/submitting patches as appropriate.
> 
> I think it would be a nice move if this wasn't just left to us users,
> especially since it is a process of suddenly finding missing parts or
> large changes in functionality in something like an easter egg hunt.
> 
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

The only features that we know are missing in Xl, and we have no current
plan of implementing them, are in the list below.
Please do tell if you find any other features that you need, currently
in xend, but missing in Xl.


> i.e. take something like Remus that had officially become a part of
> Xen some time back but isn't possible to use with PV domUs with any
> reasonable amount of effort. And not by formal decision, after a
> "heads up" mail, but just by chance. A few months I was still thinking
> I would be able to use it in a hosting product but "whoops" not
> working anymore.

Now we are more agressive at deprecating components that haven't been
properly maintained.
In the case of Remus, fortunately Shriram stepped up to the task.


> Back to xl:
> Probably noone really objects removing xm by now since it's not really
> working anymore once the system has xl support and the two are not
> compatible. It has to be in everyones interest that there is no
> unneeded code to maintain and that the core devs LIKE that code and
> that people can rely on it being maintained for the years to come.
> It doesn't matter if we type 'xl' or 'xm', it has to *work* :)
> 
> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" and other projects know how much
> time they have to clean up their code. I.e. cobbler/koan is suddenly
> broken after 4 years and people can't install domUs anymore. :)

This is a reasonable request.
I would also like to mention that we have a wiki page regarding
migration to 4.1 with a few notes about Xl:
http://wiki.xen.org/xenwiki/MigrationGuideToXen4.1%2B
Also Ian just wrote an Xl feature list:
http://wiki.xen.org/wiki/XL


Features missing in Xl, with no current plan to introduce them (as usual
contributions are welcome and encouraged):

- python support in VM config files;
- an RPC interface;
- managed domain;
- pv-usb;
- netchannel2;
- pv-scsi;


Features missing in Xl, work in progress:

- Remus;
- machine parsable output from xl create.



Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
Linux, the only feature that I believe people might miss is managed
domains. However it should be pretty easy to script that feature on top
of Xl and I believe that Debian might even be already doing something
like that with xend.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel