Re: xend deprecation

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

Il 04/09/2013 18:33, Konrad Rzeszutek Wilk ha scritto:
> On Wed, Sep 04, 2013 at 04:34:30PM +0100, Ian Campbell wrote:
>> On Wed, 2013-09-04 at 16:18 +0100, George Dunlap wrote:
>>> On Wed, Sep 4, 2013 at 3:04 PM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote:
>>>> On Wed, Sep 04, 2013 at 08:29:07AM +0100, Ian Campbell wrote:
>>>>> On Tue, 2013-09-03 at 23:06 -0700, Matt Wilson wrote:
>>>>>> On Tue, Sep 03, 2013 at 09:03:46AM +0100, Ian Campbell wrote:
>>>>>>> On Mon, 2013-09-02 at 13:32 -0700, Matt Wilson wrote:
>>>>>>>> Live migration between a system running xend to a system that doesn't
>>>>>>>> support xend would be a nice-to-have. That probably means some support
>>>>>>>> for SXP parsing either in libxl or in some compatibility tool.
>>>>>>> This already works by using xl on the source side, e.g. a guest started
>>>>>>> with xend on 4.1 can be migrated with 4.1's xl to 4.2.
>>>>>>>
>>>>>>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg02191.html
>>>>>> xl doesn't run everywhere that we need it to.
>>>>> Details please, or we aren't going to be able to even think about how to
>>>>> solve this for you.
>>>>>
>>>>> BTW You can also do a xend migration to e.g. 4.2 (using the xend whichis
>>>>> in 4.2) and the use 4.2's xl to do a localhost migrate or a second
>>>>> remote migrate to another 4.2 system.
>>>>>
>>>>> xend's deprecation has been on the cards, and widely known, for several
>>>>> releases now. It is time to quit stalling and start moving. I intend to
>>>>> post a patch deleting it as soon as 4.4 is out the door.
>>>> And I think I might have to lobby hard against removing it.
>> If by lobby you mean "step up to maintain" then please do.
> I can surely do that, but I would prefer to have the issues fixed.
>
>>>> There are issues that are stopping us from using it:
>>>>
>>>>   - No status in xl list -l when only dom0 is present.
>> xl list -l produces a tonne of output here when only dom0 is present.
>>
>>>>   - 'xl list -l' says 'Domain name must be specified' even though the '-l'
>>>>     is for 'Output all VM details'
>> Not here it doesn't.
>>
>> IIRC this was a bug in 4.1 or 4.2 timescales, which is now fixed.
> Odd, I am running Xen 4.3. Hm, time to rebase.
>
>>>>   - xl list -l for PV guest has bug: it’s not formated S-expression text.
>> This is a feature not a bug. However you can request an sxp
>> compatibility mode (I forget how, check the manpage). Note that this
>> doesn't include new features, so you would be advised to make plans to
>> switch to consuming the json variant.
>>
>>>>   - No console in xl list -l, so can't get  tty console port.
>> That one should be easily fixable
>>
>>>>   - xl uses SSH for migration. We need SSL daemon or socat like xend has.
>> You can provide any tool you like to run instead of ssh, including an
>> ssl daemon/client or socat. See the manpage.
> Right, except that the socat part does not work as the 'ssh' arguments
> are encoded in the code. I am not saying that these are 'earth-shattering hard
> to fix' it just that they should be done before Xend is gone.
>
>>>> Those should be fixed at some point :-) Problem is that other things
>>>> keep on popping up on the radar and hence we end up using xend.
>>> Uum, when were you going to report these?  A lot of us were under the
>>> impression that xl behaved sufficiently like xend for anyone who
>>> cared.
>>>
>>> Maybe we should make an announcement (on blog, xen-users, xen-devel,
>>> and xen-announce) that there has been a proposal to make 4.4 the last
>>> release with xend, and so it's important to report all bugs / missing
>>> features of xl so we can get them fixed by the 4.4 release?

I think is a good idea, if will not removed on xen 4.4 at least disabled 
it by default to get more visible the new xl to the users and get more 
feedback.

About very small thing present in xend and not in xl not reported for 
now is the autocompletion name of domU in commandsmissed.

I think is good do a similar thing with qemu traditional with 
deprecation and massive comunication of a certain deadline.
Also in this case will be good disabling it by default to accentuate its 
deprecation.
Upstream qemu needs more testing/support to have hvm domUs 
performance/features/bugfixes improved.

>> Didn't we do this for 4.2 or 4.3? We didn't get much feedback.
> No idea.
>> Ian.
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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