[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.4 development update

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?

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.