Re: [Xen-devel] Xen 4.4 development update

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 23/09/13 08:24, Jan Beulich wrote:
> > > > On 20.09.13 at 18:04, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> > On 20/09/13 16:57, Olaf Hering wrote:
> > > On Mon, Sep 16, George Dunlap wrote:
> > >
> > > > * xend still in tree
> > > >    - xl list -l on a dom0-only system
> > > >    - xl list -l doesn't contain tty console port
> > > >    - Alternate transport support for migration
> > > libxl has no pvscsi support. This is listed as "SCSI LUN/Host
> > > passthrough (PVSCSI)" in the page below.
> > > Is PVUSB already handled by libxl?
> > >
> > > http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison
> > Are you personally using PVSCSI, and/or pvusb, and/or do you know any
> > large downstreams and/or user bases that depend on them?
> We certainly have customers using pvSCSI (for some I perhaps
> should say "would like to", as so far they can't due to limitations
> of the protocol).
>
> > There was never any intention of making xl have every single feature of
> > xend; only the features that people cared enough about to argue for /
> > implement themselves. The list above was generated from a recent
> > discussion of why Oracle and Amazon object to removing xend at this
> > time.  If these is an important feature to you, the time to say
> > something about it was 1 year ago.
> I'm pretty certain the question of both pvSCSI and pvUSB not
> being there in xl was raised before.
>
> And no, I don't agree with your initial statement. The outcome of
> the most recent community call was "make all regressions of xl vs
> xm a blocker for 4.4". Of course I don't read this to imply features
> no-one uses, but I certainly read this to cover features that some
> people use, even if they're not a majority.
Well, that's exactly the sticking point -- what is a "feature no-one 
uses" and not?  How are we to know if we don't have this kind of 
discussion and ask about it?
That's my point -- we've been saying, "we're going to get rid of xend 
soon, let us know what features are missing from xl" for two years now.  
It's time to actually make a list of specific features which are 
blockers and get them implemented.
And I don't think we should just give every feature of xend a pass. I 
don't really think we *can* if we wanted to -- for instance, we can't 
allow executable python code in the config file.  According to the 
rubric you propose above, then if there's one guy who is using python in 
his config files, then we're stuck with xend forever.
Furthermore, ultimately code talks.  If those features are valuable, 
then it should be worth someone's time to implement them in xl.  If 
they're not valuable enough for someone to implement, then are they 
really valuable enough to keep?
I think that if the people on the community call want those features, 
it's time to put their money where their mouth is and actually implement 
them in xl.
> And the use case for pvSCSI is pretty obvious: Without it, in order
> to do e.g. a tape backup, you have to PCI-pass-through a whole
> HBA to a guest instead of just the single SCSI tape device that
> you need the guest to have access to.
It's obvious if you know people who do that, but I don't.  This is what 
I was asking Olaf for.  I wouldn't consider this a blocker just to check 
a box on the feature list.  But if you've got a number of customers 
using it, then of course it's an important feature, and we should try to 
implement it before dropping xend.  (Though again, I think that at some 
point, if it's not important enough for someone to implement, it's not 
important enough to keep supporting.)
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel