Re: [RFC] Trusty plans for xen-api/xcp
On 02/10/2014 03:00 PM, Stefan Bader wrote: On 10.02.2014 15:47, George Dunlap wrote: On Mon, Feb 10, 2014 at 9:24 AM, Robie Basak robie.ba...@ubuntu.com wrote: On Fri, Jan 31, 2014 at 01:45:44PM +, Robie Basak wrote: Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. I have filed bug 1278352 to have these packages removed from Trusty. FYI, I just had a chat with the lead xapi developer. He's said that unfortunately management has told them not to work on the open-source xapi packages (at least for now); so if there is nobody in the community willing to maintain it, then I think removing it is probably the best option. On a related note -- what version of libvirt / Xen will be in Trusty? The SuSE guys have made a lot of progress on getting good support for libxl and libvirt; that's probably the best way forward. -George Libvirt version 1.2.x (currently .1) not sure whether this may or may not change until release. Xen ... at least 4.3.2 (not yet uploaded) but there has been some interest (for the better Arm support) on 4.4. Depends a bit how soon/late the release is compared to Trusty. Anyway, I would like to make xl the default for new setups at least. I am currently using it a lot together with virt-manager (though it has some odd ends still) and I am being told that openstack integration is done via libvirt at least (not sure they mandate the stack being xl or not). I've just downloaded a daily snapshot from 03/13 and gone through the process of installing Xen and testing basic functionality. A couple of suggestions: * The wiki minimally needs to be tweaked a bit for the new release; I can do that when it's closer to the release. * It would be good to be able to boot Xen be default if it's installed, without having to muck about with setting the default. Is there any chance of patching grub to reverse the default order? * It would be better to default to xl rather than xend * If you update to Xen 4.4 (which was released earlier this week) and use 1.2.2 for libvirt, the libvirt/libxl driver should be really solid. If you do update to 4.4, let me know when that's done, and I can help test the libvirt integration. Another advantage of upgrading to 4.4 is that nested virtualization is much improved: you can feasibly install Xen inside a an HVM guest, and then install HVM guests inside of that. Nested virtualization is really slow, but it may be easier to test. -George -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Trusty plans for xen-api/xcp
On 03/17/2014 09:38 AM, Stefan Bader wrote: On 14.03.2014 18:58, George Dunlap wrote: On 02/10/2014 03:00 PM, Stefan Bader wrote: On 10.02.2014 15:47, George Dunlap wrote: On Mon, Feb 10, 2014 at 9:24 AM, Robie Basak robie.ba...@ubuntu.com wrote: On Fri, Jan 31, 2014 at 01:45:44PM +, Robie Basak wrote: Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. I have filed bug 1278352 to have these packages removed from Trusty. FYI, I just had a chat with the lead xapi developer. He's said that unfortunately management has told them not to work on the open-source xapi packages (at least for now); so if there is nobody in the community willing to maintain it, then I think removing it is probably the best option. On a related note -- what version of libvirt / Xen will be in Trusty? The SuSE guys have made a lot of progress on getting good support for libxl and libvirt; that's probably the best way forward. -George Libvirt version 1.2.x (currently .1) not sure whether this may or may not change until release. Xen ... at least 4.3.2 (not yet uploaded) but there has been some interest (for the better Arm support) on 4.4. Depends a bit how soon/late the release is compared to Trusty. Anyway, I would like to make xl the default for new setups at least. I am currently using it a lot together with virt-manager (though it has some odd ends still) and I am being told that openstack integration is done via libvirt at least (not sure they mandate the stack being xl or not). I've just downloaded a daily snapshot from 03/13 and gone through the process of installing Xen and testing basic functionality. A couple of suggestions: * The wiki minimally needs to be tweaked a bit for the new release; I can do that when it's closer to the release. * It would be good to be able to boot Xen be default if it's installed, without having to muck about with setting the default. Is there any chance of patching grub to reverse the default order? * It would be better to default to xl rather than xend * If you update to Xen 4.4 (which was released earlier this week) and use 1.2.2 for libvirt, the libvirt/libxl driver should be really solid. If you do update to 4.4, let me know when that's done, and I can help test the libvirt integration. Another advantage of upgrading to 4.4 is that nested virtualization is much improved: you can feasibly install Xen inside a an HVM guest, and then install HVM guests inside of that. Nested virtualization is really slow, but it may be easier to test. -George Hi George, I am trying to get 4.4 into Trusty right now. In that package I changed the default to xl already. The default boot is something that should be possible. Maybe not immediately as I want to get the 4.4 update through feature freeze. But I wanted to make some changes to grub integration anyway, so that would be part of that. Awesome, thanks. The wiki, you mean a xen.org wiki or some Ubuntu? I meant this page: https://help.ubuntu.com/community/Xen The sed runes it has you type in to change the grub boot order aren't correct anymore, for example; and if we default to xl it should ideally be updated to reflect that. Currently I got the new package only on my ppa (apt-add-repository ppa:smb/xen). Adding that you could have a look at the intended package earlier. Note that this always needs a recompiled libvirt due to libxen dependencies. I will try to keep an up to date recompiled version in my PPA as well. Is it not possible for libvirt to use Xen / KVM / HyperV / whatever if they are present, and not use them if they are not present? If not, it doesn't seem to be very well designed... Anyway, I'll give it a spin sometime this week. Thanks! -George -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Trusty plans for xen-api/xcp
On 17.03.2014 16:57, George Dunlap wrote: On 03/17/2014 09:38 AM, Stefan Bader wrote: On 14.03.2014 18:58, George Dunlap wrote: On 02/10/2014 03:00 PM, Stefan Bader wrote: On 10.02.2014 15:47, George Dunlap wrote: On Mon, Feb 10, 2014 at 9:24 AM, Robie Basak robie.ba...@ubuntu.com wrote: On Fri, Jan 31, 2014 at 01:45:44PM +, Robie Basak wrote: Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. I have filed bug 1278352 to have these packages removed from Trusty. FYI, I just had a chat with the lead xapi developer. He's said that unfortunately management has told them not to work on the open-source xapi packages (at least for now); so if there is nobody in the community willing to maintain it, then I think removing it is probably the best option. On a related note -- what version of libvirt / Xen will be in Trusty? The SuSE guys have made a lot of progress on getting good support for libxl and libvirt; that's probably the best way forward. -George Libvirt version 1.2.x (currently .1) not sure whether this may or may not change until release. Xen ... at least 4.3.2 (not yet uploaded) but there has been some interest (for the better Arm support) on 4.4. Depends a bit how soon/late the release is compared to Trusty. Anyway, I would like to make xl the default for new setups at least. I am currently using it a lot together with virt-manager (though it has some odd ends still) and I am being told that openstack integration is done via libvirt at least (not sure they mandate the stack being xl or not). I've just downloaded a daily snapshot from 03/13 and gone through the process of installing Xen and testing basic functionality. A couple of suggestions: * The wiki minimally needs to be tweaked a bit for the new release; I can do that when it's closer to the release. * It would be good to be able to boot Xen be default if it's installed, without having to muck about with setting the default. Is there any chance of patching grub to reverse the default order? * It would be better to default to xl rather than xend * If you update to Xen 4.4 (which was released earlier this week) and use 1.2.2 for libvirt, the libvirt/libxl driver should be really solid. If you do update to 4.4, let me know when that's done, and I can help test the libvirt integration. Another advantage of upgrading to 4.4 is that nested virtualization is much improved: you can feasibly install Xen inside a an HVM guest, and then install HVM guests inside of that. Nested virtualization is really slow, but it may be easier to test. -George Hi George, I am trying to get 4.4 into Trusty right now. In that package I changed the default to xl already. The default boot is something that should be possible. Maybe not immediately as I want to get the 4.4 update through feature freeze. But I wanted to make some changes to grub integration anyway, so that would be part of that. Awesome, thanks. The wiki, you mean a xen.org wiki or some Ubuntu? I meant this page: https://help.ubuntu.com/community/Xen The sed runes it has you type in to change the grub boot order aren't correct anymore, for example; and if we default to xl it should ideally be updated to reflect that. Ah yeah. I just happened to meddle around with that today after another poor soul got lost with the runes there. But I fully agree, there should be a simpler way. Currently I got the new package only on my ppa (apt-add-repository ppa:smb/xen). Adding that you could have a look at the intended package earlier. Note that this always needs a recompiled libvirt due to libxen dependencies. I will try to keep an up to date recompiled version in my PPA as well. Is it not possible for libvirt to use Xen / KVM / HyperV / whatever if they are present, and not use them if they are not present? It does do that. The problem there comes from the different library versioning approach we share with Debian. Since the version is part of the library name, a libvirt compiled agains libvirt 4.3 will keep using the old library. This works surprisingly well when running Xen-4.4 but as soon as you try to launch a guest libvirtd will segfault. This is why you need a libvirt package compiled against libxen-4.4 which the PPA tries to ensure (though I currently have to do that manually as long as things are not in the main archive). If not, it doesn't seem to be very well designed... Anyway, I'll give it a spin sometime this week. Thanks! Thanks for that. If you find anything let me know. -Stefan -George signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or
Re: [RFC] Trusty plans for xen-api/xcp
On 02/10/2014 03:00 PM, Stefan Bader wrote: On 10.02.2014 15:47, George Dunlap wrote: On Mon, Feb 10, 2014 at 9:24 AM, Robie Basak robie.ba...@ubuntu.com wrote: On Fri, Jan 31, 2014 at 01:45:44PM +, Robie Basak wrote: Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. I have filed bug 1278352 to have these packages removed from Trusty. FYI, I just had a chat with the lead xapi developer. He's said that unfortunately management has told them not to work on the open-source xapi packages (at least for now); so if there is nobody in the community willing to maintain it, then I think removing it is probably the best option. On a related note -- what version of libvirt / Xen will be in Trusty? The SuSE guys have made a lot of progress on getting good support for libxl and libvirt; that's probably the best way forward. -George Libvirt version 1.2.x (currently .1) not sure whether this may or may not change until release. Xen ... at least 4.3.2 (not yet uploaded) but there has been some interest (for the better Arm support) on 4.4. Depends a bit how soon/late the release is compared to Trusty. I think it should be out by the end of the month, but you know how predictable software development is. :-) We just checked in a patch series that should make libvirt on libxl really stable (fixed a bunch of obscure race conditions, apparently it now runs for days of stress testing without any problems), so if you could get 4.4 in, that would be great. (If not, I think the series may end up being backported to 4.3 at some point, but I'm not sure.) Anyway, I would like to make xl the default for new setups at least. I am currently using it a lot together with virt-manager (though it has some odd ends still) and I am being told that openstack integration is done via libvirt at least (not sure they mandate the stack being xl or not). Yeah, long-term I think libvirt is going to be the most suitable thing from both sides. -George -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Trusty plans for xen-api/xcp
On Fri, Jan 31, 2014 at 01:45:44PM +, Robie Basak wrote: Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. I have filed bug 1278352 to have these packages removed from Trusty. Robie signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Trusty plans for xen-api/xcp
On 10.02.2014 15:47, George Dunlap wrote: On Mon, Feb 10, 2014 at 9:24 AM, Robie Basak robie.ba...@ubuntu.com wrote: On Fri, Jan 31, 2014 at 01:45:44PM +, Robie Basak wrote: Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. I have filed bug 1278352 to have these packages removed from Trusty. FYI, I just had a chat with the lead xapi developer. He's said that unfortunately management has told them not to work on the open-source xapi packages (at least for now); so if there is nobody in the community willing to maintain it, then I think removing it is probably the best option. On a related note -- what version of libvirt / Xen will be in Trusty? The SuSE guys have made a lot of progress on getting good support for libxl and libvirt; that's probably the best way forward. -George Libvirt version 1.2.x (currently .1) not sure whether this may or may not change until release. Xen ... at least 4.3.2 (not yet uploaded) but there has been some interest (for the better Arm support) on 4.4. Depends a bit how soon/late the release is compared to Trusty. Anyway, I would like to make xl the default for new setups at least. I am currently using it a lot together with virt-manager (though it has some odd ends still) and I am being told that openstack integration is done via libvirt at least (not sure they mandate the stack being xl or not). -Stefan signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Trusty plans for xen-api/xcp
On Thu, Jan 23, 2014 at 03:23:12PM +0100, Stefan Bader wrote: Debian has removed xen-api/xen-api-libs from testing and were thinking about removing it completely from Sid as nobody cared about it. Citrix is working on some overhaul but have not come forward with something usable, yet. When being asked they came up asking whether the build failure could get fixed and then the current code be used for Trusty. Unless somebody steps up to maintain xen-api, I don't think it makes sense to continue keeping these packages in Ubuntu, given that Debian have removed them from testing and the existing packages broken (and, it seems, thus stuck in trusty-proposed). So we should remove them from trusty-proposed. If the packages get reinstated in Debian testing before our Debian Import Freeze, then we can have them in Trusty. AIUI, our OpenStack packaging uses libvirt and libxen (-4.3?), so won't be affected. If I'm wrong here, please could somebody point this out now? [...] So basically throwing the general question into the air what should be done with the xen-api* packages: removed (maybe bad as that could break upgrades from P), make them compile and decide whether to replace nova plugins by libvirt use or keep them and add libvirt use or ...? The right time to drop support for something is in a new release. If xen-api doesn't ship in Trusty, then I don't think there's an issue with there not being an upgrade path. As a distribution, we can only pass on to users what is available upstream. Perhaps we should just add a release note to say that xen-api is no longer available. Robie signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[RFC] Trusty plans for xen-api/xcp
This (and related) package has a bit of an upstream maintenance issue. All those packages together (blktap, xen-api, xen-api-libs, openxenserver?) make up the open source part of Citrix Xenserver. This was introduced in Precise LTS and (please correct me if I am wrong) was to some degree used to integrate Xen into OpenStack. However there did not seem to be a lot of upstream work going into keeping it in a working state (packages are in universe). At least the xen-api-libs source package was FTBS in Saucy. And it is again (for a different reason) FTBS in Trusty. Debian has removed xen-api/xen-api-libs from testing and were thinking about removing it completely from Sid as nobody cared about it. Citrix is working on some overhaul but have not come forward with something usable, yet. When being asked they came up asking whether the build failure could get fixed and then the current code be used for Trusty. While this probably could be done (though the current ocaml type related problem I have my problems in understanding, but I am no ocaml developer), I would have my doubts about its quality (there unlikely will be much effort put into it). On the other hand, it is universe. But at least with respect to OpenStack we should not rely on xcp to integrate Xen hosts. At least not as the only option. Currently I find much less xcp package in Trusty but this very likely is because of the build failure of xen-api-libs. Is there work being done to check whether libvirt could be used in nova instead (maybe already done). So basically throwing the general question into the air what should be done with the xen-api* packages: removed (maybe bad as that could break upgrades from P), make them compile and decide whether to replace nova plugins by libvirt use or keep them and add libvirt use or ...? -Stefan signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
