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

[Florian Heigl <florian.heigl@xxxxxxxxx>]

Hi Ian and all,

2012/1/25 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Wed, 2012-01-25 at 08:26 +0000, Likarpenkov Alexander wrote:
>> Здравствуйте!
>>
>> Во вторник, двадцать четвертого января 2012 года, в 20:41:38 Вы писали:
>>  DM> I use the xl toolstack, not xm.  I don't think xm is being actively
>>  DM> maintained, at least not for current releases.
>>
>> You can in a nutshell what better xl xm?
>
> xm (and the underlying xend daemon) have been effectively unmaintained
> since Xen 3.4 or perhaps even earlier (we take band-aids and obvious
> fixups but no proper maintenance has been occurring).

thats not an advantage of xl imho.
xm / xend being an unstable mess and xl being blazingly fast is one.

> In the opinion of the core developers xend is unmaintainable and so we
> have chosen to focus our efforts on libxl (a library designed to provide
> a common "bottom third" for any Xen toolstack) and the xl toolstack that
> is built using it. libxl is also supported by libvirt and there are
> plans for xapi (the XCP toolstack) to use it as well.

this is another piece of un-maintained-ness?
libvirt + xend just went away because nobody even complained when
libvirt suddenly defaulted to not build xen support. Ok, probably
because most Xen users don't need a gui tool to start their VMs :)

> 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.

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.

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. :)

Greetings,
Florian

p.s.: I am aware I will have to make up for this mail in beer once
there is an opportunity.

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

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