xend: handle extended PCI configuration space when saving state

Ian Campbell writes ("Re: [Xen-devel] xend deprecation"):

Quoted 3 lines

create !
title it xl improve support for migration over non-sshlike tunnels thanks

...

Quoted 4 lines

Konrad, what is the exact requirement here? You mention socat which just takes an IP address and connects to it and pipes stuff back and forth (crypto optional). I suspect the sending side of that can be done with a thin wrapper which provides the 'ssh like' command line interface,

I think it can be done with the existing xl interface, TBH, but it's probably ugly. I would have no problem with an option which made xl make the network connection itself.

Quoted 3 lines

so
what is needed is a daemon listening on a known port which can fork + exec xl migrate-receive for each connection?

I think this should be doable by running xl migrate-receive out of inetd, or some kind of socket-activation-based feature of an init-replacement (eg upstart).

If not this should be fixed.

Ian.

Tim Deegan

2013-09-04 15:49 UTC #13 lore raw

Re: xend deprecation

Quoted 7 lines · Ian Campbell

Quoted 4 lines · George Dunlap
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?
Didn't we do this for 4.2 or 4.3? We didn't get much feedback.

Indeed. The 4.2 release notes say:

The XEND toolstack is now deprecated and should be expected to be removed in the 4.3 timescale. Therefore it is strongly recommended that users evaluate Xen 4.2 with XL for their use cases and report any omissions or blockers such that they can be addressed for 4.3. Fixes for serious functionality gaps will also be considered for backport to the 4.2.x releases.

I guess we're now on "expected to be removed in the 4.5 timescale"?

Tim.

Ian Jackson

2013-09-04 16:17 UTC #14 lore raw

Re: xend deprecation

Tim Deegan writes ("Re: [Xen-devel] xend deprecation"):

Quoted 1 line

At 16:34 +0100 on 04 Sep (1378312470), Ian Campbell wrote:

...

Quoted 4 lines

Quoted 1 line
Didn't we do this for 4.2 or 4.3? We didn't get much feedback.
Indeed. The 4.2 release notes say:

Quoted 8 lines

The XEND toolstack is now deprecated and should be expected to be removed in the 4.3 timescale. Therefore it is strongly recommended that users evaluate Xen 4.2 with XL for their use cases and report any omissions or blockers such that they can be addressed for 4.3. Fixes for serious functionality gaps will also be considered for backport to the 4.2.x releases.
I guess we're now on "expected to be removed in the 4.5 timescale"?

Surely we can still remove it in 4.4, having advertised that we were going to remove it in 4.3.

Ian.

Ian Campbell

2013-09-04 16:24 UTC #15 lore raw

Re: xend deprecation

Quoted 14 lines · Ian Jackson

Tim Deegan writes ("Re: [Xen-devel] xend deprecation"):
Quoted 1 line
At 16:34 +0100 on 04 Sep (1378312470), Ian Campbell wrote:
...
Quoted 11 lines
Quoted 1 line
Didn't we do this for 4.2 or 4.3? We didn't get much feedback.
Indeed. The 4.2 release notes say:
The XEND toolstack is now deprecated and should be expected to be removed in the 4.3 timescale. Therefore it is strongly recommended that users evaluate Xen 4.2 with XL for their use cases and report any omissions or blockers such that they can be addressed for 4.3. Fixes for serious functionality gaps will also be considered for backport to the 4.2.x releases.

Quoted 4 lines

Quoted 1 line
I guess we're now on "expected to be removed in the 4.5 timescale"?
Surely we can still remove it in 4.4, having advertised that we were going to remove it in 4.3.

Well, either that or the people insisting it remain need to step up and take over maintenance. Amazon appear to be offering to do that, at least to some extent.

I nearly said "remain Supported" above, but the reality is that it effectively hasn't been Supported by this community for many releases now. I don't know to what extent Matt and Steven are offering to maintain it. Depending on the answer to that we should consider moving xend to a separate tree.

Ian.

Konrad Rzeszutek Wilk

2013-09-04 16:33 UTC #16 lore raw

Re: xend deprecation

Quoted 25 lines · Ian Campbell

Quoted 24 lines · George Dunlap
Quoted 22 lines · Konrad Rzeszutek Wilk
Quoted 21 lines · Ian Campbell
Quoted 6 lines · Matt Wilson
Quoted 5 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.
Quoted 6 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
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.

Quoted 5 lines

Quoted 4 lines
Quoted 4 lines
There are issues that are stopping us from using it:
- No status in xl list -l when only dom0 is present.

Quoted 8 lines

xl list -l produces a tonne of output here when only dom0 is present.
Quoted 2 lines
Quoted 2 lines
- '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.

Quoted 8 lines

Quoted 2 lines
Quoted 2 lines
- 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.

Quoted 8 lines

Quoted 1 line
Quoted 1 line
- No console in xl list -l, so can't get tty console port.
That one should be easily fixable
Quoted 1 line
Quoted 1 line
- 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.

Quoted 9 lines

Quoted 9 lines
Quoted 4 lines
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.

Quoted 6 lines

Quoted 4 lines
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?
Didn't we do this for 4.2 or 4.3? We didn't get much feedback.

No idea.

Quoted 3 lines

Ian.

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

George Dunlap

2013-09-05 09:13 UTC #17 lore raw

Re: xend deprecation

Quoted 23 lines · Konrad Rzeszutek Wilk

Quoted 22 lines · Ian Campbell
Quoted 21 lines · George Dunlap
Quoted 19 lines · Konrad Rzeszutek Wilk
Quoted 18 lines · Ian Campbell
Quoted 10 lines · Matt Wilson
Quoted 8 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.

Quoted 6 lines

Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
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.

You mean you prefer to have the xl issues fixed? I think we all do; so instead of lobbying hard to remove xend, you can lobby hard to get the outstanding issues fixed. :-)

-George

Konrad Rzeszutek Wilk

2013-09-06 13:36 UTC #18 lore raw

Re: xend deprecation

Quoted 27 lines · George Dunlap

Quoted 26 lines · Konrad Rzeszutek Wilk
Quoted 25 lines · Ian Campbell
Quoted 24 lines · George Dunlap
Quoted 22 lines · Konrad Rzeszutek Wilk
Quoted 21 lines · Ian Campbell
Quoted 10 lines · Matt Wilson
Quoted 8 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.

Quoted 7 lines

Quoted 3 lines
Quoted 2 lines
Quoted 1 line
Quoted 1 line
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.
You mean you prefer to have the xl issues fixed? I think we all do; so instead of lobbying hard to remove xend, you can lobby hard to get the outstanding issues fixed. :-)

Of course I would love to have the issues fixes. But I am running in a time management problem and I don't thing we will get them all (along with the other changes we (Oracle) would like to get done) by the deadline.

Hence as a safety net I am proposing that if we don't get them done, we postpone the killing of xend.

Ian Campbell

2013-09-06 13:49 UTC #19 lore raw

Re: xend deprecation

Quoted 2 lines · Konrad Rzeszutek Wilk

Hence as a safety net I am proposing that if we don't get them done, we postpone the killing of xend.

It's been two releases now, how many more do you want?

We can't just be keeping unmaintained code around indefinitely. Are you volunteering to add your name to MAINTAINERS file next to Matt and Steven?

I would also note that xend being removed from upstream xen does not in any way preclude your continuing to use and develop it. However removing it does remove a bunch of confusion from our end users about what they should use and removes a burden from the project as a whole.

Ian

Jan Beulich

2013-09-06 14:01 UTC #20 lore raw

Re: xend deprecation

Quoted 7 lines

Quoted 1 line
Quoted 1 line · Ian Campbell
Quoted 2 lines · Konrad Rzeszutek Wilk
Hence as a safety net I am proposing that if we don't get them done, we postpone the killing of xend.
It's been two releases now, how many more do you want?

Quoted 8 lines

We can't just be keeping unmaintained code around indefinitely. Are you volunteering to add your name to MAINTAINERS file next to Matt and Steven?
I would also note that xend being removed from upstream xen does not in any way preclude your continuing to use and develop it. However removing it does remove a bunch of confusion from our end users about what they should use and removes a burden from the project as a whole.

Can't we, for 4.4 at least, simply disable CONFIG_XEND by default, to make the earlier verbal announcement more obvious to consumers of the tree? (That's not to say that I'd like it kept; I'm just saying that knowing that verbal announcements of planned feature removal is usually less efficient than forcing people to re-enable their feature, thus - hopefully - grokking the news.)

Jan

Ian Campbell

2013-09-06 14:15 UTC #21 lore raw

Re: xend deprecation

Quoted 11 lines · Jan Beulich

Quoted 11 lines
Quoted 1 line
Quoted 1 line · Ian Campbell
Quoted 2 lines · Konrad Rzeszutek Wilk
Hence as a safety net I am proposing that if we don't get them done, we postpone the killing of xend.
It's been two releases now, how many more do you want?
We can't just be keeping unmaintained code around indefinitely. Are you volunteering to add your name to MAINTAINERS file next to Matt and Steven?

Quoted 8 lines

Quoted 4 lines
I would also note that xend being removed from upstream xen does not in any way preclude your continuing to use and develop it. However removing it does remove a bunch of confusion from our end users about what they should use and removes a burden from the project as a whole.
Can't we, for 4.4 at least, simply disable CONFIG_XEND by default, to make the earlier verbal announcement more obvious to consumers of the tree?

I think this is the minimum we should do.

Ian.

Fabio Fantoni

2013-09-05 10:18 UTC #22 lore raw

Re: xend deprecation

Il 04/09/2013 18:33, Konrad Rzeszutek Wilk ha scritto:

Quoted 49 lines · Ian Campbell

Quoted 22 lines · George Dunlap
Quoted 21 lines
Quoted 19 lines · Konrad Rzeszutek Wilk
Quoted 18 lines · Ian Campbell
Quoted 10 lines · Matt Wilson
Quoted 8 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 2 lines
Quoted 2 lines
- '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.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
- 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.
Quoted 1 line
Quoted 1 line
- No console in xl list -l, so can't get tty console port.

Quoted 19 lines

Quoted 5 lines
That one should be easily fixable
Quoted 1 line
Quoted 1 line
- 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.
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
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.

Quoted 8 lines

Quoted 1 line
Didn't we do this for 4.2 or 4.3? We didn't get much feedback.
No idea.
Quoted 2 lines
Ian.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

George Dunlap

2013-09-05 10:27 UTC #23 lore raw

Re: xend deprecation

Quoted 73 lines · Fabio Fantoni

Il 04/09/2013 18:33, Konrad Rzeszutek Wilk ha scritto:
Quoted 53 lines · Ian Campbell
Quoted 22 lines · George Dunlap
Quoted 21 lines
Quoted 19 lines · Konrad Rzeszutek Wilk
Quoted 18 lines · Ian Campbell
Quoted 10 lines · Matt Wilson
Quoted 8 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
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.
Quoted 11 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 3 lines
Quoted 3 lines
- '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.
Quoted 10 lines
Quoted 2 lines
Quoted 2 lines
- 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.
Quoted 1 line
Quoted 1 line
- No console in xl list -l, so can't get tty console port.
That one should be easily fixable
Quoted 18 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
- 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.
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
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?

Quoted 5 lines

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.

qemu is a bit different than xend: it is entirely possible to migrate a VM started with xend to a system using only xl. I don't think the same is true for qemu; so we will probably be keeping qemu-traditional around for some time after qemu-xen has reached feature parity (which it still has yet to do).

-George

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

George Dunlap

2013-09-05 10:46 UTC #24 lore raw

Re: xend deprecation

In reply to George Dunlap

Quoted 31 lines · Ian Campbell

Quoted 24 lines · George Dunlap
Quoted 22 lines · Konrad Rzeszutek Wilk
Quoted 21 lines · Ian Campbell
Quoted 6 lines · Matt Wilson
Quoted 5 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
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.

Quoted 7 lines

If by lobby you mean "step up to maintain" then please do.
Quoted 3 lines
Quoted 3 lines
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.

FWIW:

# xl list -l
[

]

This is from c/s 0c006b41a283a0a569c863d44abde5aa5750ae01, dated August 13.

-George

Konrad Rzeszutek Wilk

2013-09-04 16:30 UTC #25 lore raw

Re: xend deprecation

Quoted 39 lines · George Dunlap

Quoted 37 lines · Konrad Rzeszutek Wilk
Quoted 17 lines · Ian Campbell
Quoted 6 lines · Matt Wilson
Quoted 5 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
There are issues that are stopping us from using it:
- No status in xl list -l when only dom0 is present.
- 'xl list -l' says 'Domain name must be specified' even though the '-l' is for 'Output all VM details'
- xl list -l for PV guest has bug: it’s not formated S-expression text.
- No console in xl list -l, so can't get tty console port.
- xl uses SSH for migration. We need SSL daemon or socat like xend has.

Quoted 6 lines

Quoted 2 lines
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.

I got overwhelmed with other things and this dropped from my radar. This thread got me digging through my notes.

Quoted 5 lines

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?

Sounds sensible.

Quoted 2 lines

-George

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Ian Campbell

2013-09-12 12:52 UTC #26 lore raw

PATCH 1/1 xl: print runtime info in "xl list -l"

Quoted 1 line · Konrad Rzeszutek Wilk

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

Which bits of status are you interested in?

I'm thinking something like the following, which will include the content of libxl_dominfo for every domain.

8<----------------------------------

Quoted 1 line

From ee9fb6c41cd53afd4983fd2e21ad0e39f178c066 Mon Sep 17 00:00:00 2001

From: Ian Campbell <[email protected]>
Date: Thu, 12 Sep 2013 13:50:33 +0100
Subject: [PATCH] xl: print runtime info in "xl list -l"

Include dom0 runtime information, but not domain config.

---
 tools/libxl/xl_cmdimpl.c |   74 ++++++++++++++++++++++++++++------------------
 1 file changed, 46 insertions(+), 28 deletions(-)

tools/libxl/xl_cmdimpl.c +46 ~~-28~~

index 884f050..46fdafc 100644
@@ -298,7 +298,8 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
 }
 
 static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
-                                            libxl_domain_config *d_config)
+                                            libxl_domain_config *d_config,
+                                            libxl_dominfo *d_info)
 {
     yajl_gen_status s;

@@ -317,13 +318,25 @@ static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
     if (s != yajl_gen_status_ok)
         goto out;
 
-    s = yajl_gen_string(hand, (const unsigned char *)"config",
-                        sizeof("config")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_domain_config_gen_json(hand, d_config);
-    if (s != yajl_gen_status_ok)
-        goto out;
+    if (d_config) {
+        s = yajl_gen_string(hand, (const unsigned char *)"config",
+                            sizeof("config")-1);
+        if (s != yajl_gen_status_ok)
+            goto out;
+        s = libxl_domain_config_gen_json(hand, d_config);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+
+    if (d_info) {
+        s = yajl_gen_string(hand, (const unsigned char *)"info",
+                            sizeof("info")-1);
+        if (s != yajl_gen_status_ok)
+            goto out;
+        s = libxl_dominfo_gen_json(hand, d_info);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
 
     s = yajl_gen_map_close(hand);
     if (s != yajl_gen_status_ok)

@@ -350,7 +363,7 @@ static void printf_info(enum output_format output_format,
         return;
     }
 
-    s = printf_info_one_json(hand, domid, d_config);
+    s = printf_info_one_json(hand, domid, d_config, NULL);
     if (s != yajl_gen_status_ok)
         goto out;

@@ -2990,7 +3003,7 @@ static void reboot_domain(uint32_t domid, libxl_evgen_domain_death **deathw,
     }
 }
 
-static void list_domains_details(const libxl_dominfo *info, int nb_domain)
+static void list_domains_details(libxl_dominfo *info, int nb_domain)
 {
     libxl_domain_config d_config;

@@ -3017,26 +3030,31 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
         s = yajl_gen_status_ok;
 
     for (i = 0; i < nb_domain; i++) {
-        /* no detailed info available on dom0 */
-        if (info[i].domid == 0)
-            continue;
-        rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
-        if (rc)
-            continue;
-        CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
-        libxl_domain_config_init(&d_config);
-        parse_config_data(config_source, (char *)data, len, &d_config, NULL);
-        if (default_output_format == OUTPUT_FORMAT_JSON)
-            s = printf_info_one_json(hand, info[i].domid, &d_config);
-        else
+        fprintf(stderr, "dom%d\n", info[i].domid);
+
+        if ( info[i].domid > 0 ) {
+            fprintf(stderr, "parse d_config for dom%d\n", info[i].domid);
+            rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
+            if (rc)
+                continue;
+            CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
+            libxl_domain_config_init(&d_config);
+            parse_config_data(config_source, (char *)data, len, &d_config, NULL);
+        } else { fprintf(stderr, "no d_config\n"); }
+        if (default_output_format == OUTPUT_FORMAT_JSON) {
+            s = printf_info_one_json(hand, info[i].domid,
+                                     i == 0 ? NULL : &d_config, &info[i]);
+            if (s != yajl_gen_status_ok)
+                goto out;
+        } else
             printf_info_sexp(info[i].domid, &d_config);
-        libxl_domain_config_dispose(&d_config);
-        free(data);
-        free(config_source);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
 
+        if ( info[i].domid > 0 ) {
+            libxl_domain_config_dispose(&d_config);
+            free(data);
+            free(config_source);
+        }
+    }
     if (default_output_format == OUTPUT_FORMAT_JSON) {
         s = yajl_gen_array_close(hand);
         if (s != yajl_gen_status_ok)

Signature · 1 line

1.7.10.4

Konrad Rzeszutek Wilk

2013-09-25 17:42 UTC #27 lore raw

Re: [PATCH] xl: print runtime info in "xl list -l"

Quoted 4 lines · Ian Campbell

Quoted 1 line · Konrad Rzeszutek Wilk
- No status in xl list -l when only dom0 is present.
Which bits of status are you interested in?

The

    (status 2)

field.

Quoted 4 lines

I'm thinking something like the following, which will include the content of libxl_dominfo for every domain.

Quoted 8 lines

8<----------------------------------
Quoted 1 line
From ee9fb6c41cd53afd4983fd2e21ad0e39f178c066 Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Thu, 12 Sep 2013 13:50:33 +0100
Subject: [PATCH] xl: print runtime info in "xl list -l"
Include dom0 runtime information, but not domain config.

With that I get (with /etc/xen/xl.conf having output_mode=sxp)

-bash-4.1# xl list -l
dom0
no d_config
(domain

        (domid 0)
        (create_info)
        (hvm 1)
        (hap True)
        (oos <default>)
        (ssidref 0)
        (name (null))
        (uuid 00000000-0000-0000-0000-000000000000)
        (xsdata (null))
        (platformdata (null))
        (build_info)
        (max_vcpus 0)
        (tsc_mode (null))
        (max_memkb 0)
        (target_memkb 45887743)
        (nomigrate True)
        (image
                (hvm
                        (firmware )
                        (video_memkb 140277926854668)
                        (shadow_memkb 140280103390500)
                        (pae True)
                        (apic True)
                        (acpi True)
                        (nx False)
                        (viridian True)
                        (hpet False)
                        (vpt_align <default>)
                        (timer_mode (null))
                        (nestedhvm True)
                        (stdvga False)
                        (vnc <default>)

Segmentation fault

While under xm:
-bash-4.1# xm list -l
(domain

    (domid 0)
    (cpu_weight 256)
    (cpu_cap 0)
    (pool_name Pool-0)
    (bootloader '')
    (vcpus 4)
    (cpus ((0 1 2 3) (0 1 2 3) (0 1 2 3) (0 1 2 3)))
    (on_poweroff destroy)
    (on_crash restart)
    (uuid 00000000-0000-0000-0000-000000000000)
    (bootloader_args '')
    (name Domain-0)
    (on_reboot restart)
    (maxmem 6144)
    (memory 2048)
    (shadow_memory 0)
    (features '')
    (on_xend_start ignore)
    (on_xend_stop ignore)
    (cpu_time 11.138272406)
    (online_vcpus 4)
    (image (linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0)))
    (status 2)
    (state r-----)

)

Let me (once I am done with this email backlog) look at this and see if I can make the segfault go away.

Thanks for the prototype!

Quoted 126 lines

---
 tools/libxl/xl_cmdimpl.c |   74 ++++++++++++++++++++++++++++------------------
 1 file changed, 46 insertions(+), 28 deletions(-)

tools/libxl/xl_cmdimpl.c +46 ~~-28~~

index 884f050..46fdafc 100644
@@ -298,7 +298,8 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
 }
 
 static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
-                                            libxl_domain_config *d_config)
+                                            libxl_domain_config *d_config,
+                                            libxl_dominfo *d_info)
 {
     yajl_gen_status s;

@@ -317,13 +318,25 @@ static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
     if (s != yajl_gen_status_ok)
         goto out;
 
-    s = yajl_gen_string(hand, (const unsigned char *)"config",
-                        sizeof("config")-1);
-    if (s != yajl_gen_status_ok)
-        goto out;
-    s = libxl_domain_config_gen_json(hand, d_config);
-    if (s != yajl_gen_status_ok)
-        goto out;
+    if (d_config) {
+        s = yajl_gen_string(hand, (const unsigned char *)"config",
+                            sizeof("config")-1);
+        if (s != yajl_gen_status_ok)
+            goto out;
+        s = libxl_domain_config_gen_json(hand, d_config);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+
+    if (d_info) {
+        s = yajl_gen_string(hand, (const unsigned char *)"info",
+                            sizeof("info")-1);
+        if (s != yajl_gen_status_ok)
+            goto out;
+        s = libxl_dominfo_gen_json(hand, d_info);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
 
     s = yajl_gen_map_close(hand);
     if (s != yajl_gen_status_ok)

@@ -350,7 +363,7 @@ static void printf_info(enum output_format output_format,
         return;
     }
 
-    s = printf_info_one_json(hand, domid, d_config);
+    s = printf_info_one_json(hand, domid, d_config, NULL);
     if (s != yajl_gen_status_ok)
         goto out;

@@ -2990,7 +3003,7 @@ static void reboot_domain(uint32_t domid, libxl_evgen_domain_death **deathw,
     }
 }
 
-static void list_domains_details(const libxl_dominfo *info, int nb_domain)
+static void list_domains_details(libxl_dominfo *info, int nb_domain)
 {
     libxl_domain_config d_config;

@@ -3017,26 +3030,31 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
         s = yajl_gen_status_ok;
 
     for (i = 0; i < nb_domain; i++) {
-        /* no detailed info available on dom0 */
-        if (info[i].domid == 0)
-            continue;
-        rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
-        if (rc)
-            continue;
-        CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
-        libxl_domain_config_init(&d_config);
-        parse_config_data(config_source, (char *)data, len, &d_config, NULL);
-        if (default_output_format == OUTPUT_FORMAT_JSON)
-            s = printf_info_one_json(hand, info[i].domid, &d_config);
-        else
+        fprintf(stderr, "dom%d\n", info[i].domid);
+
+        if ( info[i].domid > 0 ) {
+            fprintf(stderr, "parse d_config for dom%d\n", info[i].domid);
+            rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
+            if (rc)
+                continue;
+            CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
+            libxl_domain_config_init(&d_config);
+            parse_config_data(config_source, (char *)data, len, &d_config, NULL);
+        } else { fprintf(stderr, "no d_config\n"); }
+        if (default_output_format == OUTPUT_FORMAT_JSON) {
+            s = printf_info_one_json(hand, info[i].domid,
+                                     i == 0 ? NULL : &d_config, &info[i]);
+            if (s != yajl_gen_status_ok)
+                goto out;
+        } else
             printf_info_sexp(info[i].domid, &d_config);
-        libxl_domain_config_dispose(&d_config);
-        free(data);
-        free(config_source);
-        if (s != yajl_gen_status_ok)
-            goto out;
-    }
 
+        if ( info[i].domid > 0 ) {
+            libxl_domain_config_dispose(&d_config);
+            free(data);
+            free(config_source);
+        }
+    }
     if (default_output_format == OUTPUT_FORMAT_JSON) {
         s = yajl_gen_array_close(hand);
         if (s != yajl_gen_status_ok)

Signature · 1 line

1.7.10.4

Ian Campbell

2013-09-25 17:56 UTC #28 lore raw

Re: [PATCH] xl: print runtime info in "xl list -l"

Quoted 8 lines · Konrad Rzeszutek Wilk

Quoted 4 lines · Ian Campbell
Quoted 1 line · Konrad Rzeszutek Wilk
- No status in xl list -l when only dom0 is present.
Which bits of status are you interested in?
The
    (status 2)

Oh, I thought you might mean the "(state r-----)" bit which I know and understand. I've no idea what this 2 status is -- any idea what it means/relates to?

Quoted 7 lines

field.
Quoted 6 lines
I'm thinking something like the following, which will include the content of libxl_dominfo for every domain.
8<----------------------------------

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
From ee9fb6c41cd53afd4983fd2e21ad0e39f178c066 Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Thu, 12 Sep 2013 13:50:33 +0100
Subject: [PATCH] xl: print runtime info in "xl list -l"
Include dom0 runtime information, but not domain config.
With that I get (with /etc/xen/xl.conf having output_mode=sxp)

Actually, I probably didn't hook up the sxp case, oops!

Should be easy enough to add though.

Ian.

Konrad Rzeszutek Wilk

2013-09-25 18:25 UTC #29 lore raw

Re: [PATCH] xl: print runtime info in "xl list -l"

Quoted 5 lines · Ian Campbell

Quoted 4 lines · Konrad Rzeszutek Wilk
Quoted 3 lines · Ian Campbell
Quoted 1 line · Konrad Rzeszutek Wilk
- No status in xl list -l when only dom0 is present.

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
Which bits of status are you interested in?
The
    (status 2)
Oh, I thought you might mean the "(state r-----)" bit which I know and understand. I've no idea what this 2 status is -- any idea what it means/relates to?

It looks to be
(status 2)
(state -b----)

  def _stateGet(self):                                                        
        # Lets try and reconsitute the state from xc                            
        # first lets try and get the domain info                                
        # from xc - this will tell us if the domain                             
        # exists                                                                
        info = dom_get(self.getDomid())                                         
        if info is None or info['shutdown']:                                    
            # We are either HALTED or SUSPENDED                                 
            # check saved image exists                                          
            from xen.xend import XendDomain                                     
            managed_config_path = \                                             
                XendDomain.instance()._managed_check_point_path( \              
                    self.get_uuid())                                            
            if os.path.exists(managed_config_path):                             
                return XEN_API_VM_POWER_STATE_SUSPENDED                         
            else:                                                               
                return XEN_API_VM_POWER_STATE_HALTED                            
        elif info['crashed']:                                                   
            # Crashed                                                           
            return XEN_API_VM_POWER_STATE_CRASHED                               
        else:                                                                   
            # We are either RUNNING or PAUSED                                   
            if info['paused']:                                                  
                return XEN_API_VM_POWER_STATE_PAUSED                            
            else:                                                               
                return XEN_API_VM_POWER_STATE_RUNNING

which is
XEN_API_VM_POWER_STATE_HALTED = 0
XEN_API_VM_POWER_STATE_PAUSED = 1
XEN_API_VM_POWER_STATE_RUNNING = 2
XEN_API_VM_POWER_STATE_SUSPENDED = 3
XEN_API_VM_POWER_STATE_SHUTTINGDOWN = 4
XEN_API_VM_POWER_STATE_CRASHED = 5
XEN_API_VM_POWER_STATE_UNKNOWN = 6

Quoted 13 lines

Quoted 13 lines
field.
Quoted 11 lines
I'm thinking something like the following, which will include the content of libxl_dominfo for every domain.
8<----------------------------------
Quoted 1 line
From ee9fb6c41cd53afd4983fd2e21ad0e39f178c066 Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Thu, 12 Sep 2013 13:50:33 +0100
Subject: [PATCH] xl: print runtime info in "xl list -l"

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
Include dom0 runtime information, but not domain config.
With that I get (with /etc/xen/xl.conf having output_mode=sxp)
Actually, I probably didn't hook up the sxp case, oops!

Ah.

Quoted 5 lines

Should be easy enough to add though.
Ian.

Ian Campbell

2013-09-25 17:59 UTC #30 lore raw

Re: [PATCH] xl: print runtime info in "xl list -l"

Quoted 2 lines · Konrad Rzeszutek Wilk

While under xm:
-bash-4.1# xm list -l

BTW, if you can gather a representative set of such outputs from the sorts of configurations you support we can look at heading straight there instead of faulting in the interesting fields one at a time...

Ian.

Konrad Rzeszutek Wilk

2013-09-25 18:27 UTC #31 lore raw

Re: [PATCH] xl: print runtime info in "xl list -l"

Quoted 7 lines · Ian Campbell

Quoted 2 lines · Konrad Rzeszutek Wilk
While under xm:
-bash-4.1# xm list -l
BTW, if you can gather a representative set of such outputs from the sorts of configurations you support we can look at heading straight there instead of faulting in the interesting fields one at a time...

Let me talk to Zhigang on how to make that possible.

Thank you!

Quoted 4 lines

Ian.

Wei Liu

2013-10-28 15:51 UTC #32 lore raw

Re: [PATCH] xl: print runtime info in "xl list -l"

Quoted 11 lines · Konrad Rzeszutek Wilk

Quoted 7 lines · Ian Campbell
Quoted 2 lines · Konrad Rzeszutek Wilk
While under xm:
-bash-4.1# xm list -l
BTW, if you can gather a representative set of such outputs from the sorts of configurations you support we can look at heading straight there instead of faulting in the interesting fields one at a time...
Let me talk to Zhigang on how to make that possible.

How is this going?

Quoted 10 lines

Thank you!
Quoted 4 lines
Ian.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Ian Campbell

2013-09-12 14:02 UTC #33 lore raw

Re: xend deprecation

Quoted 2 lines · Konrad Rzeszutek Wilk

- No console in xl list -l, so can't get tty console port.

Together with the previous patch this can be resoled with the following, I think. I'm not sure this is the best way to do it though, although dominfo is mostly "runtime" info and this fits....

8<----------------------------

Quoted 1 line

From 4cffdf9517c668a176f37fa58236f4eb2fd4bbb0 Mon Sep 17 00:00:00 2001

From: Ian Campbell <[email protected]>
Date: Thu, 12 Sep 2013 14:41:06 +0100
Subject: [PATCH] libxl: expose the POV console tty in the dominfo.

---
 tools/libxl/libxl.c         |   38 ++++++++++++++++++++++++++++----------
 tools/libxl/libxl_types.idl |    2 ++
 2 files changed, 30 insertions(+), 10 deletions(-)

tools/libxl/libxl.c +28 ~~-10~~

index 1bce4bb..8dea15f 100644
@@ -510,9 +510,12 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
     return 0;
 }
 
-static void xcinfo2xlinfo(const xc_domaininfo_t *xcinfo,
+static void xcinfo2xlinfo(libxl__gc *gc,
+                          const xc_domaininfo_t *xcinfo,
                           libxl_dominfo *xlinfo)
 {
+    libxl_dominfo_init(xlinfo);
+
     memcpy(&(xlinfo->uuid), xcinfo->handle, sizeof(xen_domain_handle_t));
     xlinfo->domid = xcinfo->domain;
     xlinfo->ssidref = xcinfo->ssidref;

@@ -539,10 +542,17 @@ static void xcinfo2xlinfo(const xc_domaininfo_t *xcinfo,
     xlinfo->cpupool = xcinfo->cpupool;
     xlinfo->domain_type = (xcinfo->flags & XEN_DOMINF_hvm_guest) ?
         LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV;
+
+    if (xcinfo->domaindomid && libxl_console_get_tty(CTX, xcinfo->domain, 0,
+                                                      LIBXL_CONSOLE_TYPE_PV,
+                                                      &xlinfo->console_tty) < 0)
+        LOG(WARN, "unable to get dom%d pv console tty\n", xcinfo->domain);
+
 }
 
 libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
 {
+    GC_INIT(ctx);
     libxl_dominfo *ptr;
     int i, ret;
     xc_domaininfo_t info[1024];

@@ -551,38 +561,46 @@ libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
     ptr = calloc(size, sizeof(libxl_dominfo));
     if (!ptr) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating domain info");
-        return NULL;
+        goto err;
     }
 
     ret = xc_domain_getinfolist(ctx->xch, 0, 1024, info);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         free(ptr);
-        return NULL;
+        ptr = NULL;
+        goto err;
     }
 
     for (i = 0; i < ret; i++) {
-        xcinfo2xlinfo(&info[i], &ptr[i]);
+        xcinfo2xlinfo(gc, &info[i], &ptr[i]);
     }
     *nb_domain_out = ret;
+err:
+    GC_FREE;
     return ptr;
 }
 
 int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
-                      uint32_t domid) {
+                      uint32_t domid)
+{
+    GC_INIT(ctx);
     xc_domaininfo_t xcinfo;
-    int ret;
+    int ret, rc = ERROR_INVAL;
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return ERROR_FAIL;
     }
-    if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
+    if (ret==0 || xcinfo.domain != domid) goto err;;
 
     if (info_r)
-        xcinfo2xlinfo(&xcinfo, info_r);
-    return 0;
+        xcinfo2xlinfo(gc, &xcinfo, info_r);
+    rc = 0;
+err:
+    GC_FREE;
+    return rc;
 }
 
 static int cpupool_info(libxl__gc *gc,

@@ -3764,7 +3782,7 @@ retry_transaction:
         abort_transaction = 1;
         goto out;
     }
-    xcinfo2xlinfo(&info, &ptr);
+    xcinfo2xlinfo(gc, &info, &ptr);
     uuid = libxl__uuid2string(gc, ptr.uuid);
     libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);

tools/libxl/libxl_types.idl +2 -0

index 10f95f4..6de305b 100644
@@ -200,6 +200,8 @@ libxl_dominfo = Struct("dominfo",[
     ("shutdown",    bool),
     ("dying",       bool),
 
+    ("console_tty", string),
+
     # Valid iff (shutdown||dying).
     #
     # Otherwise set to a value guaranteed not to clash with any valid

Signature · 1 line

1.7.10.4

Wei Liu

2013-10-21 14:10 UTC #34 lore raw

Re: xend deprecation

On Wed, Sep 04, 2013 at 10:04:14AM -0400, Konrad Rzeszutek Wilk wrote:
[...]

Quoted 2 lines

There are issues that are stopping us from using it:

I look at these xl items from time to time and see if I can fix them but they come out a little bit more complex than I expect.

Xl will store DomU configs in its private storage location and retrievs them as it see fit. This behavior is causing a series of issues.

For 'xl list -l', the detail info of a domain is retrieved from the stored config file.

Quoted 1 line

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

This would not work because there is no config file for Dom0.

Quoted 2 lines

- 'xl list -l' says 'Domain name must be specified' even though the '-l' is for 'Output all VM details'

Haven't traced this one down, but I presume this is caused by the same thing.

Quoted 1 line

- No console in xl list -l, so can't get tty console port.

This would not work because apparently you cannot specify a tty in DomU's config file -- that's allcoated by xenconsoled.

Along with the above issues, xl save/restored will only use the stored config file which makes it impossible to persist any runtime info across save/restore -- one significant defect is that VM's MAC address changes every time unless it is specified in the original config file.

These issues are all connected in a way -- runtime info is not retrieved / updated / preserved. What I have in mind is that we might need to introduce a mechanism to pull info from Xenstore, serialize / deserialize config info / update stored config file when necessary.

Comments?

Wei.

Zhigang Wang

2013-10-21 15:14 UTC #35 lore raw

Re: xend deprecation

Quoted 34 lines · Wei Liu

On Wed, Sep 04, 2013 at 10:04:14AM -0400, Konrad Rzeszutek Wilk wrote:
[...]
Quoted 2 lines
There are issues that are stopping us from using it:
I look at these xl items from time to time and see if I can fix them but they come out a little bit more complex than I expect.
Xl will store DomU configs in its private storage location and retrievs them as it see fit. This behavior is causing a series of issues.
For 'xl list -l', the detail info of a domain is retrieved from the stored config file.
Quoted 1 line
- No status in xl list -l when only dom0 is present.
This would not work because there is no config file for Dom0.
Quoted 2 lines
- 'xl list -l' says 'Domain name must be specified' even though the '-l' is for 'Output all VM details'
Haven't traced this one down, but I presume this is caused by the same thing.
Quoted 1 line
- No console in xl list -l, so can't get tty console port.
This would not work because apparently you cannot specify a tty in DomU's config file -- that's allcoated by xenconsoled.
Along with the above issues, xl save/restored will only use the stored config file which makes it impossible to persist any runtime info across save/restore -- one significant defect is that VM's MAC address changes every time unless it is specified in the original config file.

Quoted 6 lines

These issues are all connected in a way -- runtime info is not retrieved / updated / preserved. What I have in mind is that we might need to introduce a mechanism to pull info from Xenstore, serialize / deserialize config info / update stored config file when necessary.
Comments?

Long time ago, when I work on it, I have the same feeling (I haven't confirm the latest code yet).

xend is a daemon: it handles all VM state change. With xl, a private storage location for each VM is the corresponding solution for now.

My suggestion with my limited knowledge is: remove this private storage location and get all the info from xenstore/hypercall.

Thanks,

Zhigang

Ian Campbell

2013-10-21 15:33 UTC #36 lore raw

Re: xend deprecation

In reply to Wei Liu

Quoted 3 lines · Wei Liu

Quoted 1 line
- No status in xl list -l when only dom0 is present.
This would not work because there is no config file for Dom0.

I sent a PoC patch which adds the content of libxl_dominfo (ie. the runtime info) to the listing alongside the domain config. For dom0 only the runtime info is included, but that is what is needed here.

Quoted 5 lines

Quoted 2 lines
- 'xl list -l' says 'Domain name must be specified' even though the '-l' is for 'Output all VM details'
Haven't traced this one down, but I presume this is caused by the same thing.

Yes, I think dom0 can be special cased to only care about libxl_dominfo and not libxl_domain_config. I think I might have included that in the PoC.

I thought I'd added a bug to track the thread with that PoC in it, but apparently not. See the subthread starting at <[email protected]>

I thought I'd posted the tty thing too, apparently not. It was like this and hooked into the patch above to actually get printed.

Ian.

commit 4cffdf9517c668a176f37fa58236f4eb2fd4bbb0

Author: Ian Campbell <[email protected]>
Date:   Thu Sep 12 14:41:06 2013 +0100

libxl: expose the POV console tty in the dominfo.

tools/libxl/libxl.c +28 ~~-10~~

index 1bce4bb..8dea15f 100644
@@ -510,9 +510,12 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
     return 0;
 }
 
-static void xcinfo2xlinfo(const xc_domaininfo_t *xcinfo,
+static void xcinfo2xlinfo(libxl__gc *gc,
+                          const xc_domaininfo_t *xcinfo,
                           libxl_dominfo *xlinfo)
 {
+    libxl_dominfo_init(xlinfo);
+
     memcpy(&(xlinfo->uuid), xcinfo->handle, sizeof(xen_domain_handle_t));
     xlinfo->domid = xcinfo->domain;
     xlinfo->ssidref = xcinfo->ssidref;

@@ -539,10 +542,17 @@ static void xcinfo2xlinfo(const xc_domaininfo_t *xcinfo,
     xlinfo->cpupool = xcinfo->cpupool;
     xlinfo->domain_type = (xcinfo->flags & XEN_DOMINF_hvm_guest) ?
         LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV;
+
+    if (xcinfo->domaindomid && libxl_console_get_tty(CTX, xcinfo->domain, 0,
+                                                      LIBXL_CONSOLE_TYPE_PV,
+                                                      &xlinfo->console_tty) < 0)
+        LOG(WARN, "unable to get dom%d pv console tty\n", xcinfo->domain);
+
 }
 
 libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
 {
+    GC_INIT(ctx);
     libxl_dominfo *ptr;
     int i, ret;
     xc_domaininfo_t info[1024];

@@ -551,38 +561,46 @@ libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
     ptr = calloc(size, sizeof(libxl_dominfo));
     if (!ptr) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating domain info");
-        return NULL;
+        goto err;
     }
 
     ret = xc_domain_getinfolist(ctx->xch, 0, 1024, info);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         free(ptr);
-        return NULL;
+        ptr = NULL;
+        goto err;
     }
 
     for (i = 0; i < ret; i++) {
-        xcinfo2xlinfo(&info[i], &ptr[i]);
+        xcinfo2xlinfo(gc, &info[i], &ptr[i]);
     }
     *nb_domain_out = ret;
+err:
+    GC_FREE;
     return ptr;
 }
 
 int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
-                      uint32_t domid) {
+                      uint32_t domid)
+{
+    GC_INIT(ctx);
     xc_domaininfo_t xcinfo;
-    int ret;
+    int ret, rc = ERROR_INVAL;
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return ERROR_FAIL;
     }
-    if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
+    if (ret==0 || xcinfo.domain != domid) goto err;;
 
     if (info_r)
-        xcinfo2xlinfo(&xcinfo, info_r);
-    return 0;
+        xcinfo2xlinfo(gc, &xcinfo, info_r);
+    rc = 0;
+err:
+    GC_FREE;
+    return rc;
 }
 
 static int cpupool_info(libxl__gc *gc,

@@ -3764,7 +3782,7 @@ retry_transaction:
         abort_transaction = 1;
         goto out;
     }
-    xcinfo2xlinfo(&info, &ptr);
+    xcinfo2xlinfo(gc, &info, &ptr);
     uuid = libxl__uuid2string(gc, ptr.uuid);
     libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);

tools/libxl/libxl_types.idl +2 -0

index 10f95f4..6de305b 100644
@@ -200,6 +200,8 @@ libxl_dominfo = Struct("dominfo",[
     ("shutdown",    bool),
     ("dying",       bool),
 
+    ("console_tty", string),
+
     # Valid iff (shutdown||dying).
     #
     # Otherwise set to a value guaranteed not to clash with any valid

Ian Campbell

2013-10-21 15:35 UTC #37 lore raw

Re: xend deprecation

In reply to Wei Liu

Quoted 6 lines · Wei Liu

These issues are all connected in a way -- runtime info is not retrieved / updated / preserved. What I have in mind is that we might need to introduce a mechanism to pull info from Xenstore, serialize / deserialize config info / update stored config file when necessary.
Comments?

I agree. I have long thought that we need a way to resynthesize a libxl_domain_config from a running domain directly instead of by reparsing the config, which is likely to be stale.

This could also be used as part of migration which also suffers from issues where e.g. the migrated domain gets a new random mac or reverts to the original memory target. In this case instead of sending the config file over the migration wire we'd want to switch to using the JSON generation and add autogenerated JSON parsing for use on the other end.

I started to hack on such a thing (see below, as you can see it is a bit WIP!). If you wanted to pick it up that would be awesome.

Ian.

commit 47a05fa3fa53761f889bec0bc2884fe927ac988f

Author: Ian Campbell <[email protected]>
Date:   Mon Sep 23 12:52:07 2013 +0100

begin to implement libxl_domain_running_config

tools/libxl/libxl.c +3 -3

index 8dea15f..0ae145f 100644
@@ -543,9 +543,9 @@ static void xcinfo2xlinfo(libxl__gc *gc,
     xlinfo->domain_type = (xcinfo->flags & XEN_DOMINF_hvm_guest) ?
         LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV;
 
-    if (xcinfo->domaindomid && libxl_console_get_tty(CTX, xcinfo->domain, 0,
-                                                      LIBXL_CONSOLE_TYPE_PV,
-                                                      &xlinfo->console_tty) < 0)
+    if (xcinfo->domain && libxl_console_get_tty(CTX, xcinfo->domain, 0,
+                                                LIBXL_CONSOLE_TYPE_PV,
+                                                &xlinfo->console_tty) < 0)
         LOG(WARN, "unable to get dom%d pv console tty\n", xcinfo->domain);
 
 }

tools/libxl/libxl.h +11 -0

index be19bf5..c824ad6 100644
@@ -677,6 +677,17 @@ int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
 
+/* Returns the running configuration of a domain.  If
+ * preserve_defaults is true then, where it makes sense, fields which
+ * were initially set to the default will be returned as defaults
+ * rather than presenting the actual value. e.g. this will be done for
+ * disk backend but not NIC MAC addresses. This can be useful if this
+ * call is to be used to recreate a domain, in which case you want to
+ * allow libxl to select the appropriate disk backend again but not
+ * change the MAC address. */
+int libxl_domain_running_config(libxl_ctx*, libxl_domain_config *dconfig_r,
+                                uint32_t domid, bool preserve_defaults);
+
 /* These functions each return (on success) an array of elements,
  * and the length via the int* out parameter.  These arrays and
  * their contents come from malloc, and must be freed with the

tools/libxl/libxl_dom.c +147 -0

153 lines not on this page · raw message

tools/libxl/xl_cmdimpl.c +14 -9

index 9f051f8..48815f0 100644
@@ -3007,9 +3007,9 @@ static void list_domains_details(libxl_dominfo *info, int nb_domain)
 {
     libxl_domain_config d_config;
 
-    char *config_source;
-    uint8_t *data;
-    int i, len, rc;
+    //char *config_source;
+    //uint8_t *data;
+    int i, rc;
 
     yajl_gen hand = NULL;
     yajl_gen_status s;

@@ -3032,12 +3032,17 @@ static void list_domains_details(libxl_dominfo *info, int nb_domain)
     for (i = 0; i < nb_domain; i++) {
 
         if ( info[i].domid > 0 ) {
-            rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
+            //int len;
+            //rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len);
+            //if (rc)
+            //    continue;
+            //CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
+            //libxl_domain_config_init(&d_config);
+            //parse_config_data(config_source, (char *)data, len, &d_config, NULL);
+            rc = libxl_domain_running_config(ctx, &d_config,
+                                             info[i].domid, false);
             if (rc)
                 continue;
-            CHK_ERRNO(asprintf(&config_source, "<domid %d data>", info[i].domid));
-            libxl_domain_config_init(&d_config);
-            parse_config_data(config_source, (char *)data, len, &d_config, NULL);
         }
         if (default_output_format == OUTPUT_FORMAT_JSON) {
             s = printf_info_one_json(hand, info[i].domid,

@@ -3049,8 +3054,8 @@ static void list_domains_details(libxl_dominfo *info, int nb_domain)
 
         if ( info[i].domid > 0 ) {
             libxl_domain_config_dispose(&d_config);
-            free(data);
-            free(config_source);
+            //free(data);
+            //free(config_source);
         }
     }
     if (default_output_format == OUTPUT_FORMAT_JSON) {

Stefano Stabellini

2013-09-04 12:58 UTC #38 lore raw

Re: xend deprecation

In reply to Matt Wilson

Quoted 6 lines · Matt Wilson

Quoted 5 lines · Ian Campbell
Quoted 3 lines · Matt Wilson
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.

Quoted 6 lines

Quoted 4 lines
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.

Really? How is that possible?
I am not aware of any specific hardware or software dependencies in the xl/libxl code.

If there are any, it would good to know them, because we certainly need to address them before removing xend.

Ian Campbell

2013-09-12 09:50 UTC #39 lore raw

Support for xm create -F (sxp configuration files)

In reply to Matt Wilson

create !
title it xl lacks support for xm create -F (sxp config file syntax)

Quoted 4 lines · Matt Wilson

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.

Matt mentioned elsewhere that they use "xm create -F" which takes a configuration file in the xend sxp format (I had no idea this option existed).

I don't think we really want to be adding SXP code to xm but perhaps we can produce a conversion tool?

Matt, can you provide some examples of the actual SXP you care about, we obviously don't want to be worrying about the bits which aren't actually used.

Ian.

[email protected]

2013-09-12 10:00 UTC #40 lore raw

Processed: Support for xm create -F (sxp configuration files)

Processing commands for [email protected]:

Quoted 1 line

create !

Created new bug #17 rooted at `! '
Title: `Support for xm create -F (sxp configuration files)'

Quoted 1 line

title it xl lacks support for xm create -F (sxp config file syntax)

Set title for #17 to `xl lacks support for xm create -F (sxp config file syntax)'

Quoted 2 lines · Matt Wilson

Command failed: Unknown command `On'. at /srv/xen-devel-bugs/lib/emesinae/control.pl line 437, <M> line 42. Stop processing here.

Modified/created Bugs:
- 17: http://bugs.xenproject.org/xen/bug/17 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact [email protected] with any infrastructure issues

Matt Wilson

author

2013-09-16 16:49 UTC #41 lore raw

Re: Support for xm create -F (sxp configuration files)

Quoted 9 lines · Ian Campbell

create !
title it xl lacks support for xm create -F (sxp config file syntax)
Quoted 4 lines · Matt Wilson
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.

Quoted 6 lines

Matt mentioned elsewhere that they use "xm create -F" which takes a configuration file in the xend sxp format (I had no idea this option existed).
I don't think we really want to be adding SXP code to xm but perhaps we can produce a conversion tool?

Indeed, also mentioned elsewhere it's probably not in the best interest of the project to go adding SXP support when we already have more well adopted options like json.

Quoted 3 lines

Matt, can you provide some examples of the actual SXP you care about, we obviously don't want to be worrying about the bits which aren't actually used.

Honestly I think it'd be less total work to avoid SXP altogether. There are some other differences that need to be carefully considered, and shifting config file formats is a forcing function for looking closely for those differences.

--msw

Ian Campbell

2013-11-05 14:39 UTC #42 lore raw

Re: Support for xm create -F (sxp configuration files)

close 17
thanks

Quoted 21 lines · Matt Wilson

Quoted 9 lines · Ian Campbell
create !
title it xl lacks support for xm create -F (sxp config file syntax)
Quoted 4 lines · Matt Wilson
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.
Quoted 6 lines
Matt mentioned elsewhere that they use "xm create -F" which takes a configuration file in the xend sxp format (I had no idea this option existed).
I don't think we really want to be adding SXP code to xm but perhaps we can produce a conversion tool?
Indeed, also mentioned elsewhere it's probably not in the best interest of the project to go adding SXP support when we already have more well adopted options like json.

Quoted 8 lines

Quoted 3 lines
Matt, can you provide some examples of the actual SXP you care about, we obviously don't want to be worrying about the bits which aren't actually used.
Honestly I think it'd be less total work to avoid SXP altogether. There are some other differences that need to be carefully considered, and shifting config file formats is a forcing function for looking closely for those differences.

I suppose I should close this bug.

If anyone else has a requirement for this stuff now would be a good time to say so.

I'll also add it to http://wiki.xen.org/wiki/XL#Anti-Features.

Ian.

[email protected]

2013-11-05 14:45 UTC #43 lore raw

Processed: Re: Support for xm create -F (sxp configuration files)

Processing commands for [email protected]:

Quoted 1 line

close 17

Closing bug #17

Quoted 1 line

thanks

Finished processing.

Modified/created Bugs:
- 17: http://bugs.xenproject.org/xen/bug/17

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact [email protected] with any infrastructure issues

Ian Campbell

2013-09-03 16:33 UTC #44 lore raw

In reply to Matt Wilson

Quoted 9 lines · Matt Wilson

From: Steven Noonan <[email protected]>
Newer PCI standards (e.g., PCI-X 2.0 and PCIe) introduce extended configuration space which is larger than 256 bytes. This patch uses stat() to determine the amount of space used to correctly save all of the PCI configuration space. Resets handled by the xen-pciback driver don't have this problem, as that code correctly handles saving extended configuration space.

Quoted 7 lines

Signed-off-by Steven Noonan <[email protected]>
Reviewed-by Matt Wilson <[email protected]>
[msw: adjusted commit message]
Cc Ian Jackson <[email protected]>
Cc Stefano Stabellini <[email protected]>
Cc Ian Campbell <[email protected]>
Signed-off-by Matt Wilson <[email protected]>

I've applied this and "xend: fix file descriptor leak in pci utilities" on the basis that they looked pretty simple, however in general I'm not prepared to review xend patches so I am relying on whoever wants to keep xend alive to co-review each others patches and provide the appropriate reviewed-by etc (and to take responsibility for the fallout etc).

Quoted 19 lines

---
 tools/python/xen/util/pci.py |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

tools/python/xen/util/pci.py +2 -1

index 792fb69..adeca4b 100644
@@ -521,8 +521,9 @@ def save_pci_conf_space(devs_string):
         pci_path = sysfs_mnt + SYSFS_PCI_DEVS_PATH + '/' + pci_str + \
                 SYSFS_PCI_DEV_CONFIG_PATH
         fd = os.open(pci_path, os.O_RDONLY)
+        size = os.fstat(fd).st_size
         configs = []
-        for i in range(0, 256, 4):
+        for i in range(0, size, 4):
             configs = configs + [os.read(fd,4)]
         os.close(fd)
         pci_list = pci_list + [pci_path]

Matt Wilson

author

2013-09-04 06:12 UTC #45 lore raw

Quoted 6 lines · Ian Campbell

I've applied this and "xend: fix file descriptor leak in pci utilities" on the basis that they looked pretty simple, however in general I'm not prepared to review xend patches so I am relying on whoever wants to keep xend alive to co-review each others patches and provide the appropriate reviewed-by etc (and to take responsibility for the fallout etc).

We (Amazon) can take on some of the xend life support maintenance. I'm happy to review xend code from C/Python bindings to the Python code itself.

If you'd like I'll submit a patch to MAINTAINERS for that.

--msw

Noonan, Steven

2013-09-04 06:49 UTC #46 lore raw

Quoted 8 lines · Matt Wilson

Quoted 6 lines · Ian Campbell
I've applied this and "xend: fix file descriptor leak in pci utilities" on the basis that they looked pretty simple, however in general I'm not prepared to review xend patches so I am relying on whoever wants to keep xend alive to co-review each others patches and provide the appropriate reviewed-by etc (and to take responsibility for the fallout etc).

Quoted 7 lines

We (Amazon) can take on some of the xend life support maintenance. I'm happy to review xend code from C/Python bindings to the Python code itself.
If you'd like I'll submit a patch to MAINTAINERS for that.
--msw

Agreed, I'm equally happy to maintain xend alongside Matt.

- Steven

Ian Campbell

2013-09-04 07:30 UTC #47 lore raw

Quoted 13 lines · Steven

Quoted 12 lines · Matt Wilson
Quoted 6 lines · Ian Campbell
I've applied this and "xend: fix file descriptor leak in pci utilities" on the basis that they looked pretty simple, however in general I'm not prepared to review xend patches so I am relying on whoever wants to keep xend alive to co-review each others patches and provide the appropriate reviewed-by etc (and to take responsibility for the fallout etc).
We (Amazon) can take on some of the xend life support maintenance. I'm happy to review xend code from C/Python bindings to the Python code itself.

Quoted 5 lines

Quoted 3 lines
If you'd like I'll submit a patch to MAINTAINERS for that.
--msw
Agreed, I'm equally happy to maintain xend alongside Matt.

Please do send a patch to MAINTAINERS. Try and pick the right S:tatus from the list at the top to indicate your level of support.

Ian

Ian Jackson

2013-09-04 10:14 UTC #48 lore raw