Re: [Xen-devel] [GIT PULL] remove xend for 4.5 (Was: Re: [PATCH] MAINTAINERS: Exclude xend from toolstack maintainers entry)

[George Dunlap <dunlapg@xxxxxxxxx>]

On Thu, Mar 27, 2014 at 11:18 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2014-03-27 at 11:08 +0000, George Dunlap wrote:
>> On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> wrote:
>> On my list of dependencies for removing xend, I have the following:
>>
>> * xend still in tree (x)
>>  - xl list -l on a dom0-only system
>
> Not sure what this was, doesn't sound either hard or critical though.

This is from an e-mail from Konrad, msd-id
<20130904140414.GA3188@xxxxxxxxxxxxxxxxxxx> .  He said:

- No status in xl list -l when only dom0 is present.

I'm not sure exactly what that means.  On my system, "xl list -l" on a
system with no domUs running produces an empty, but valid, array -- "[
]".  (With some extra whitespace.)

Looking further in the thread, it looks like Wei took a look at this,
and that at the moment "xl list -l" depends on reading the config file
from disk, which is a bigger architectural issue that needs to be
resolved.  You posted a PoC patch that you had started, but obviously
it hasn't been upstreamed yet.

So this should probably actually be "xl list -l contains no
information for dom0".

>
>>  - xl list -l doesn't contain tty console port
>
> I think this was fixed, wasn't it (assuming I understand what it
> actually means).
>
>>  - xl Alternate transport support for migration*
>
> What is this?

From another section of my to-do list:

* xl migrate transport improvements
 owner: None
 > See discussion here: http://bugs.xenproject.org/xen/bug/19
 - Option to connect over a plain TCP socket rather than ssh
 - xl-migrate-recieve suitable for running in inetd
 - option for above to redirect log output somewhere useful
 - Documentation for setting up alternate transports

OTOH, as a result of that discussion, it became clear that:
1. xl did have the ability to use socat / ssl; the command-line
arguments to do that are a bit wonky, however, and the documentation
is far from clear
2. The system envisioned was terribly insecure.  Receiving a domain at
the moment allows the sender trivial access to all files on the system
(including your root disk); receiving domains without authenticating
the sender means implicit trust of the entire control network.

So perhaps this wouldn't be a blocker.

>
>>  - xl support for vnc and vnclisten options with PV guests
>
> Wei fixed this already, in 4.4 even perhaps.
>
>> - xl PVSCSI support
>> - xl PVUSB support
>
> Meh.
>
> Any of the above which are still issues can still be considered to
> become blockers for 4.5, that doesn't necessarily imply they should
> block removal of xend.
>
> I think at some point we just have to rip the plaster off and I think
> that time is now. Doing so will provide additional impetus to actually
> fix any remaining issues, as it stands things have stagnated because
> people just think "oh, it's ok xend is still available".

FWIW, back in September when we had this discussion, Olaf and Jan both
said they still had customers using PVSCSI.  I responded:

 "...at some point, if it's not important enough for someone to
implement, it's not important enough to keep supporting."

To which Jan replied, "I accept that this is one way of viewing
things, but as someone implementing hypervisor side stuff for people
even if neither I nor customers of my employer immediately need it, I
think it is not completely off to expect some symmetry here: I think
it is reasonable for someone to point out deficiencies in areas (s)he
doesn't normally work on, and expect those responsible for these areas
to pick this up unless it's completely off."

And I think he has a point.

So what about the following dependency list?

* xend still in tree
 [blocker]
 - xl list -l doesn't contain information about dom0
 - xl PVSCSI support
 [nice-to-have]
 - xl Alternate transport support for migration*
 - xl PVUSB support
 [fixed]
 - xl list -l doesn't contain tty console port
 - xl support for vnc and vnclisten options with PV guests

 -George

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