Hello,
A couple of TODO items/suggestions:
1) Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
2) After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
3) After updating to Xen 4.3.2 rpms start troubleshooting/debugging the libvirt libxl driver and get it working with Xen4Centos6 system..
How does that sound like? :)
-- Pasi
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
- After updating to Xen 4.3.2 rpms start troubleshooting/debugging the libvirt libxl driver and get it working with Xen4Centos6 system..
I believe Dario Faggioli has some of this ironed out already. Dario are you on the centos-virt list ?
- KB
On Tue, Feb 18, 2014 at 07:19:07PM +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
Hmm, I'm not sure if skipping 4.3 is a good idea..
I believe the following distros/products are (or will be) shipping Xen 4.3:
- Next version of XenServer - Ubuntu 14.04 LTS - Fedora 20 - OpenSuse 13.1
It's obviously easier to live, troubleshoot and apply/backport important fixes when there are multiple parties doing it for the same(ish) codebase and sharing experiences :)
- After updating to Xen 4.3.2 rpms start troubleshooting/debugging the libvirt libxl driver and get it working with Xen4Centos6 system..
I believe Dario Faggioli has some of this ironed out already. Dario are you on the centos-virt list ?
OK.
-- Pasi
On 18/02/14 20:54, Pasi Kärkkäinen wrote:
On Tue, Feb 18, 2014 at 07:19:07PM +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
Hmm, I'm not sure if skipping 4.3 is a good idea..
I believe the following distros/products are (or will be) shipping Xen 4.3:
- Next version of XenServer
We have been testing the 4.4 RCs in XenServer and it is likely that we will switch to using 4.4 soon after its release.
David
On Wed, Feb 19, 2014 at 11:51:40AM +0000, David Vrabel wrote:
On 18/02/14 20:54, Pasi Kärkkäinen wrote:
On Tue, Feb 18, 2014 at 07:19:07PM +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
Hmm, I'm not sure if skipping 4.3 is a good idea..
I believe the following distros/products are (or will be) shipping Xen 4.3:
- Next version of XenServer
We have been testing the 4.4 RCs in XenServer and it is likely that we will switch to using 4.4 soon after its release.
That's good to know.
Thanks!
-- Pasi
On Thu, Feb 20, 2014 at 11:02:17AM +0200, Pasi Kärkkäinen wrote:
On Wed, Feb 19, 2014 at 11:51:40AM +0000, David Vrabel wrote:
On 18/02/14 20:54, Pasi Kärkkäinen wrote:
On Tue, Feb 18, 2014 at 07:19:07PM +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
Hmm, I'm not sure if skipping 4.3 is a good idea..
I believe the following distros/products are (or will be) shipping Xen 4.3:
- Next version of XenServer
We have been testing the 4.4 RCs in XenServer and it is likely that we will switch to using 4.4 soon after its release.
That's good to know.
Oh, another question.. are there any important not-yet-upstream patches in the XS dom0 kernel queue for Linux 3.10?
We should probably update the xen4centos6 linux 3.10 dom0 kernel rpms aswell.
-- Pasi
On 20/02/14 09:04, Pasi Kärkkäinen wrote:
Oh, another question.. are there any important not-yet-upstream patches in the XS dom0 kernel queue for Linux 3.10?
You can view the current XenServer patch queue at:
https://github.com/xenserver/linux-3.x.pg
There are only two things I would recommend taking but they're not ready yet.
1. Fix for high MMIO regions.
0001-x86-xen-rename-early_p2m_alloc-and-early_p2m_alloc_m.patch ... 0008-x86-remove-the-Xen-specific-_PAGE_IOMAP-PTE-flag.patch
These require more testing.
2. Preemptible privcmd hypercalls.
The current set of patches is broken and the fixed version is not ready yet.
I also note two fixes for 32-bit guests were not tagged for stable. I have now asked for these to be added to the stable trees. These are:
0160676bba69523e8b0ac83f306cce7d342ed7c8 (xen/p2m: check MFN is in range before using the m2p table)
7cde9b27e7b3a2e09d647bb4f6d94e842698d2d5 (xen: Fix possible user space selector corruption)
David
On Thu, Feb 20, 2014 at 10:51:57AM +0000, David Vrabel wrote:
On 20/02/14 09:04, Pasi Kärkkäinen wrote:
Oh, another question.. are there any important not-yet-upstream patches in the XS dom0 kernel queue for Linux 3.10?
You can view the current XenServer patch queue at:
https://github.com/xenserver/linux-3.x.pg
There are only two things I would recommend taking but they're not ready yet.
- Fix for high MMIO regions.
0001-x86-xen-rename-early_p2m_alloc-and-early_p2m_alloc_m.patch ... 0008-x86-remove-the-Xen-specific-_PAGE_IOMAP-PTE-flag.patch
These require more testing.
OK.
- Preemptible privcmd hypercalls.
The current set of patches is broken and the fixed version is not ready yet.
OK.
So we need to wait a bit with those..
I also note two fixes for 32-bit guests were not tagged for stable. I have now asked for these to be added to the stable trees. These are:
0160676bba69523e8b0ac83f306cce7d342ed7c8 (xen/p2m: check MFN is in range before using the m2p table)
7cde9b27e7b3a2e09d647bb4f6d94e842698d2d5 (xen: Fix possible user space selector corruption)
Thanks a lot!
-- Pasi
On 02/19/2014 03:51 AM, David Vrabel wrote:
On 18/02/14 20:54, Pasi Kärkkäinen wrote:
On Tue, Feb 18, 2014 at 07:19:07PM +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
Hmm, I'm not sure if skipping 4.3 is a good idea..
I believe the following distros/products are (or will be) shipping Xen 4.3:
- Next version of XenServer
We have been testing the 4.4 RCs in XenServer and it is likely that we will switch to using 4.4 soon after its release.
David,
Is this the proper qemu-xen snapshot to use for xen-4.2.4 ?
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=commit;h=6d...
Do we need any other patches in that?
Also, we are currently using blktap-9960138790b9d3610b12acd153bba20235efa4f5.tar.gz .. is that still the best version to use?
Thanks, Johnny Hughes
On Sat, Feb 22, 2014 at 06:10:41AM -0800, Johnny Hughes wrote:
On 02/19/2014 03:51 AM, David Vrabel wrote:
On 18/02/14 20:54, Pasi Kärkkäinen wrote:
On Tue, Feb 18, 2014 at 07:19:07PM +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
Hmm, I'm not sure if skipping 4.3 is a good idea..
I believe the following distros/products are (or will be) shipping Xen 4.3:
- Next version of XenServer
We have been testing the 4.4 RCs in XenServer and it is likely that we will switch to using 4.4 soon after its release.
David,
Is this the proper qemu-xen snapshot to use for xen-4.2.4 ?
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=commit;h=6d...
It seems to have the qemu-xen-4.2.4 tag, so yes, it's the one. You can also always fetch the xen 4.2.4 tarball and compare to it (it includes the qemu bits aswell).
Do we need any other patches in that?
Not that i'm aware of.. did we have any extra qemu patches on top of 4.2.3 ?
Also, we are currently using blktap-9960138790b9d3610b12acd153bba20235efa4f5.tar.gz .. is that still the best version to use?
David has to answer that..
-- Pasi
On Sat, Feb 22, 2014 at 05:32:56PM +0200, Pasi Kärkkäinen wrote:
David,
Is this the proper qemu-xen snapshot to use for xen-4.2.4 ?
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=commit;h=6d...
It seems to have the qemu-xen-4.2.4 tag, so yes, it's the one. You can also always fetch the xen 4.2.4 tarball and compare to it (it includes the qemu bits aswell).
And the Xen qemu-dm (traditional) is here: http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=8d7e96f...
I don't think qemu-upstream is really in good shape in Xen 4.2.x, so it's mostly the qemu-dm traditional that people will use with Xen 4.2.x.
-- Pasi
On 02/22/2014 07:35 AM, Pasi Kärkkäinen wrote:
On Sat, Feb 22, 2014 at 05:32:56PM +0200, Pasi Kärkkäinen wrote:
David,
Is this the proper qemu-xen snapshot to use for xen-4.2.4 ?
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=commit;h=6d...
It seems to have the qemu-xen-4.2.4 tag, so yes, it's the one. You can also always fetch the xen 4.2.4 tarball and compare to it (it includes the qemu bits aswell).
And the Xen qemu-dm (traditional) is here: http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=8d7e96f...
I don't think qemu-upstream is really in good shape in Xen 4.2.x, so it's mostly the qemu-dm traditional that people will use with Xen 4.2.x.
-- Pasi
We have been using the upstream one in the previous builds ... not sure why, its just in my notes as the one to use :)
On Sat, Feb 22, 2014 at 07:37:42AM -0800, Johnny Hughes wrote:
On 02/22/2014 07:35 AM, Pasi Kärkkäinen wrote:
On Sat, Feb 22, 2014 at 05:32:56PM +0200, Pasi Kärkkäinen wrote:
David,
Is this the proper qemu-xen snapshot to use for xen-4.2.4 ?
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=commit;h=6d...
It seems to have the qemu-xen-4.2.4 tag, so yes, it's the one. You can also always fetch the xen 4.2.4 tarball and compare to it (it includes the qemu bits aswell).
And the Xen qemu-dm (traditional) is here: http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=8d7e96f...
I don't think qemu-upstream is really in good shape in Xen 4.2.x, so it's mostly the qemu-dm traditional that people will use with Xen 4.2.x.
-- Pasi
We have been using the upstream one in the previous builds ... not sure why, its just in my notes as the one to use :)
Hmm, the normal Xen source build builds and installs both the qemu traditional and the upstream one..
Maybe I should read the el6 spec file :)
-- Pasi
On 22/02/14 14:10, Johnny Hughes wrote:
David,
Is this the proper qemu-xen snapshot to use for xen-4.2.4 ?
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=commit;h=6d...
I don't know. Stefano?
Do we need any other patches in that?
Also, we are currently using blktap-9960138790b9d3610b12acd153bba20235efa4f5.tar.gz .. is that still the best version to use?
blktap/blktap2 isn't seeing any development so this is still the one to use.
David
On 02/18/2014 01:19 PM, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
I am OK with either path, although my understanding is 4.2 => 4.4 as well.
- After updating to Xen 4.3.2 rpms start troubleshooting/debugging the libvirt libxl driver and get it working with Xen4Centos6 system..
I believe Dario Faggioli has some of this ironed out already. Dario are you on the centos-virt list ?
WRT the libvirt, libxl issues (and other libvirt things as well) ... I am fairly sure both OpenShift Origin and RDO are going to need a newer version of libvirt ... maybe we should start testing to try and get a newer version of libvirt in this stack as well (and use the same version on all 3 projects).
The current version of libvirt is close enough to the main CentOS version that virt-manager and other pieces of the current main stack works .. a newer libvirt will likely also mean recompiling or newer versions of other pieces as well.
On Tue, Feb 18, 2014 at 02:55:12PM -0600, Johnny Hughes wrote:
On 02/18/2014 01:19 PM, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
I am OK with either path, although my understanding is 4.2 => 4.4 as well.
Yep. Let's see when Xen 4.4 gets released.
Shall we start with the first step, which is upgrading to Xen 4.2.4? :)
- After updating to Xen 4.3.2 rpms start troubleshooting/debugging the libvirt libxl driver and get it working with Xen4Centos6 system..
I believe Dario Faggioli has some of this ironed out already. Dario are you on the centos-virt list ?
WRT the libvirt, libxl issues (and other libvirt things as well) ... I am fairly sure both OpenShift Origin and RDO are going to need a newer version of libvirt ... maybe we should start testing to try and get a newer version of libvirt in this stack as well (and use the same version on all 3 projects).
The current version of libvirt is close enough to the main CentOS version that virt-manager and other pieces of the current main stack works .. a newer libvirt will likely also mean recompiling or newer versions of other pieces as well.
Yeah.. I think the latest upstream libvirt libxl driver requires some libxl fixes which are only in Xen 4.4.
-- Pasi
On 02/20/2014 09:38 AM, Pasi Kärkkäinen wrote:
On Tue, Feb 18, 2014 at 02:55:12PM -0600, Johnny Hughes wrote:
On 02/18/2014 01:19 PM, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
Hello,
A couple of TODO items/suggestions:
Xen 4.2.4 was just released: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01624.html
I think we should first update Xen4Centos6 rpms to Xen 4.2.4 to have a "known good" release from the stable branch currently in use in Xen4Centos6.
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
I am OK with either path, although my understanding is 4.2 => 4.4 as well.
Yep. Let's see when Xen 4.4 gets released.
Shall we start with the first step, which is upgrading to Xen 4.2.4? :)
I am getting ready to shutdown my machine and pack it up to head out for the airport right now, to go to Scale12x:
http://www.socallinuxexpo.org/scale12x
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
<snip>
On Thu, Feb 20, 2014 at 10:26:04AM -0600, Johnny Hughes wrote:
Shall we start with the first step, which is upgrading to Xen 4.2.4? :)
I am getting ready to shutdown my machine and pack it up to head out for the airport right now, to go to Scale12x:
http://www.socallinuxexpo.org/scale12x
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
<snip>
Ok. Have fun at scale12x :)
-- Pasi
On Thu, Feb 20, 2014 at 10:26:04AM -0600, Johnny Hughes wrote:
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
I am OK with either path, although my understanding is 4.2 => 4.4 as well.
Yep. Let's see when Xen 4.4 gets released.
Shall we start with the first step, which is upgrading to Xen 4.2.4? :)
I am getting ready to shutdown my machine and pack it up to head out for the airport right now, to go to Scale12x:
http://www.socallinuxexpo.org/scale12x
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
Ok so Xen 4.2.4 and Linux 3.10.32 dom0 kernel are out in the xen4centos repo now. Also upstream released Xen 4.4.0 today.
In general Xen upstream supports live migrations from (current-1) to (current) version. So if we want to provide a (live) migration path from Xen 4.2.* to 4.4.* we probably should package Xen 4.3.2 first.. So people could migrate from 4.2.4 -> 4.3.2 -> 4.4.0.
What do you think?
(Fedora 20 has Xen 4.3.2 rpms in the updates repo, for .spec foo, if needed).
-- Pasi
On 03/10/2014 12:55 PM, Pasi Kärkkäinen wrote:
On Thu, Feb 20, 2014 at 10:26:04AM -0600, Johnny Hughes wrote:
After that, we should start packaging/testing Xen 4.3.2: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html
Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes.
my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
I am OK with either path, although my understanding is 4.2 => 4.4 as well.
Yep. Let's see when Xen 4.4 gets released.
Shall we start with the first step, which is upgrading to Xen 4.2.4? :)
I am getting ready to shutdown my machine and pack it up to head out for the airport right now, to go to Scale12x:
http://www.socallinuxexpo.org/scale12x
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
Ok so Xen 4.2.4 and Linux 3.10.32 dom0 kernel are out in the xen4centos repo now. Also upstream released Xen 4.4.0 today.
In general Xen upstream supports live migrations from (current-1) to (current) version. So if we want to provide a (live) migration path from Xen 4.2.* to 4.4.* we probably should package Xen 4.3.2 first.. So people could migrate from 4.2.4 -> 4.3.2 -> 4.4.0.
What do you think?
(Fedora 20 has Xen 4.3.2 rpms in the updates repo, for .spec foo, if needed).
Well, I would hope we can migrate from 4.2.4 to 4.4.x without requiring anything in between. Not sure if that would be possible or not.
We do need to start trying to do 4.4.x builds.
On Mon, Mar 10, 2014 at 02:09:41PM -0500, Johnny Hughes wrote:
On 03/10/2014 12:55 PM, Pasi Kärkkäinen wrote:
On Thu, Feb 20, 2014 at 10:26:04AM -0600, Johnny Hughes wrote:
> 2) After that, we should start packaging/testing Xen 4.3.2: > http://lists.xen.org/archives/html/xen-devel/2014-02/msg01622.html > > Xen 4.3 brings much improved XL toolstack in addition to a lot of other changes/fixes. my understanding was that we might skip 4.3, and rebase from 4.2 to 4.4 once that hits the released path
I am OK with either path, although my understanding is 4.2 => 4.4 as well.
Yep. Let's see when Xen 4.4 gets released.
Shall we start with the first step, which is upgrading to Xen 4.2.4? :)
I am getting ready to shutdown my machine and pack it up to head out for the airport right now, to go to Scale12x:
http://www.socallinuxexpo.org/scale12x
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
Ok so Xen 4.2.4 and Linux 3.10.32 dom0 kernel are out in the xen4centos repo now. Also upstream released Xen 4.4.0 today.
In general Xen upstream supports live migrations from (current-1) to (current) version. So if we want to provide a (live) migration path from Xen 4.2.* to 4.4.* we probably should package Xen 4.3.2 first.. So people could migrate from 4.2.4 -> 4.3.2 -> 4.4.0.
What do you think?
(Fedora 20 has Xen 4.3.2 rpms in the updates repo, for .spec foo, if needed).
Well, I would hope we can migrate from 4.2.4 to 4.4.x without requiring anything in between. Not sure if that would be possible or not.
Well I guess we just need to test that..
We do need to start trying to do 4.4.x builds.
That's what we should do :)
Fedora has rpms at least for 4.4.0-rc4, not sure about the rc5/rc6 or the final.. but I don't think the .spec file really needs to change between rc4 and the final.
-- Pasi
On Tue, Mar 11, 2014 at 10:01:28AM +0200, Pasi Kärkkäinen wrote:
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
Ok so Xen 4.2.4 and Linux 3.10.32 dom0 kernel are out in the xen4centos repo now. Also upstream released Xen 4.4.0 today.
In general Xen upstream supports live migrations from (current-1) to (current) version. So if we want to provide a (live) migration path from Xen 4.2.* to 4.4.* we probably should package Xen 4.3.2 first.. So people could migrate from 4.2.4 -> 4.3.2 -> 4.4.0.
What do you think?
(Fedora 20 has Xen 4.3.2 rpms in the updates repo, for .spec foo, if needed).
Well, I would hope we can migrate from 4.2.4 to 4.4.x without requiring anything in between. Not sure if that would be possible or not.
Well I guess we just need to test that..
We do need to start trying to do 4.4.x builds.
That's what we should do :)
Fedora has rpms at least for 4.4.0-rc4, not sure about the rc5/rc6 or the final.. but I don't think the .spec file really needs to change between rc4 and the final.
"Information for task build (f20, xen-4.4.0-0.rc4.1.fc20.src.rpm)": http://koji.fedoraproject.org/koji/taskinfo?taskID=6540303
http://kojipkgs.fedoraproject.org//work/tasks/304/6540304/xen-4.4.0-0.rc4.1....
-- Pasi
On 03/11/2014 03:05 AM, Pasi Kärkkäinen wrote:
On Tue, Mar 11, 2014 at 10:01:28AM +0200, Pasi Kärkkäinen wrote:
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
Ok so Xen 4.2.4 and Linux 3.10.32 dom0 kernel are out in the xen4centos repo now. Also upstream released Xen 4.4.0 today.
In general Xen upstream supports live migrations from (current-1) to (current) version. So if we want to provide a (live) migration path from Xen 4.2.* to 4.4.* we probably should package Xen 4.3.2 first.. So people could migrate from 4.2.4 -> 4.3.2 -> 4.4.0.
What do you think?
(Fedora 20 has Xen 4.3.2 rpms in the updates repo, for .spec foo, if needed).
Well, I would hope we can migrate from 4.2.4 to 4.4.x without requiring anything in between. Not sure if that would be possible or not.
Well I guess we just need to test that..
We do need to start trying to do 4.4.x builds.
That's what we should do :)
Fedora has rpms at least for 4.4.0-rc4, not sure about the rc5/rc6 or the final.. but I don't think the .spec file really needs to change between rc4 and the final.
"Information for task build (f20, xen-4.4.0-0.rc4.1.fc20.src.rpm)": http://koji.fedoraproject.org/koji/taskinfo?taskID=6540303
http://kojipkgs.fedoraproject.org//work/tasks/304/6540304/xen-4.4.0-0.rc4.1....
I get a forbidden on that SRPM ... do you have a copy somewhere?
On Wed, Mar 12, 2014 at 05:18:57AM -0500, Johnny Hughes wrote:
On 03/11/2014 03:05 AM, Pasi Kärkkäinen wrote:
On Tue, Mar 11, 2014 at 10:01:28AM +0200, Pasi Kärkkäinen wrote:
I should be back home and ready to go by Tuesday morning though ... so if I don't get time to do it at SCALE, I will on Tuesday.
Ok so Xen 4.2.4 and Linux 3.10.32 dom0 kernel are out in the xen4centos repo now. Also upstream released Xen 4.4.0 today.
In general Xen upstream supports live migrations from (current-1) to (current) version. So if we want to provide a (live) migration path from Xen 4.2.* to 4.4.* we probably should package Xen 4.3.2 first.. So people could migrate from 4.2.4 -> 4.3.2 -> 4.4.0.
What do you think?
(Fedora 20 has Xen 4.3.2 rpms in the updates repo, for .spec foo, if needed).
Well, I would hope we can migrate from 4.2.4 to 4.4.x without requiring anything in between. Not sure if that would be possible or not.
Well I guess we just need to test that..
We do need to start trying to do 4.4.x builds.
That's what we should do :)
Fedora has rpms at least for 4.4.0-rc4, not sure about the rc5/rc6 or the final.. but I don't think the .spec file really needs to change between rc4 and the final.
"Information for task build (f20, xen-4.4.0-0.rc4.1.fc20.src.rpm)": http://koji.fedoraproject.org/koji/taskinfo?taskID=6540303
http://kojipkgs.fedoraproject.org//work/tasks/304/6540304/xen-4.4.0-0.rc4.1....
I get a forbidden on that SRPM ... do you have a copy somewhere?
Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote:
<snip> > I get a forbidden on that SRPM ... do you have a copy somewhere? > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
How about qemu? Do we use the embedded stuff in xen tree or do we try to build an external version that works with both KVM and Xen?
Is there blktap 3 or the older blktap2 ... if the later, then I would still need to roll in the blktap2.5 code that we currently have.
OK, experts .. lets discuss !!!
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
OK, experts .. lets discuss !!!
A couple of minor suggestions gathered when installing CentOS:
* The ipxe package "obsoletes" the gpxe package. However, it doesn't actually supply all the necessary dependencies. qemu-kvm depends on the gpxe binary. The result is that you can't have both a Xen system and a KVM system installed at the same time unless you manually download gpxe (or ipxe, if you've installed KVM first) and install it with --force. This may discourage people with existing KVM systems from experimenting with Xen. Since the two don't overlap, ipxe shouldn't be listed as obsoleting gpxe.
* With the default install, Linux is configured to use the serial port, but Xen isn't. I think ideally Xen would use the serial port, and Linux running under Xen should use hvc0.
-George
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote:
<snip> > I get a forbidden on that SRPM ... do you have a copy somewhere? > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
[CC'ing Dario Faggioli and Jim Fehlig, who have been working on libvirt on libxl]
libxl is designed to be backwards compatible, so there are a number of potential libvirt versions that should all work.
What kinds of constraints are there from the CentOS side? i.e., why not just use the most recent release?
-George
On 03/13/2014 12:04 PM, George Dunlap wrote:
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote:
<snip> > I get a forbidden on that SRPM ... do you have a copy somewhere? > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
[CC'ing Dario Faggioli and Jim Fehlig, who have been working on libvirt on libxl]
libxl is designed to be backwards compatible, so there are a number of potential libvirt versions that should all work.
What kinds of constraints are there from the CentOS side? i.e., why not just use the most recent release?
The only issue with that is then we have to keep moving up to the latest version all the time ... not very "enterprisey". If we can pick a version with long term maintenance, we should be able to keep it stable more easily. Maybe the EL7 version of libvirt with patches as necessary?
If everyone really wants the Latest instead and if that is really the best version, we can do it .. I am just not convinced yet :)
On Wed, Mar 19, 2014 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
On 03/13/2014 12:04 PM, George Dunlap wrote:
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote:
<snip> > I get a forbidden on that SRPM ... do you have a copy somewhere? > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
[CC'ing Dario Faggioli and Jim Fehlig, who have been working on libvirt on libxl]
libxl is designed to be backwards compatible, so there are a number of potential libvirt versions that should all work.
What kinds of constraints are there from the CentOS side? i.e., why not just use the most recent release?
The only issue with that is then we have to keep moving up to the latest version all the time ... not very "enterprisey". If we can pick a version with long term maintenance, we should be able to keep it stable more easily. Maybe the EL7 version of libvirt with patches as necessary?
So, you asked "what version of libvirt do we need", but you still haven't actually given me any reasonable constraints; without that, I can't really answer the question. :-)
Are there any versions of libvirt designated "maintenance" releases by the community? Or is a release going to need to be "maintained" by whomever wants to keep them going (as RH will do with whatever version is in EL7)?
-George
On 03/19/2014 05:03 PM, George Dunlap wrote:
On Wed, Mar 19, 2014 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
On 03/13/2014 12:04 PM, George Dunlap wrote:
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote:
<snip> > I get a forbidden on that SRPM ... do you have a copy somewhere? > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
[CC'ing Dario Faggioli and Jim Fehlig, who have been working on libvirt on libxl]
libxl is designed to be backwards compatible, so there are a number of potential libvirt versions that should all work.
What kinds of constraints are there from the CentOS side? i.e., why not just use the most recent release?
The only issue with that is then we have to keep moving up to the latest version all the time ... not very "enterprisey". If we can pick a version with long term maintenance, we should be able to keep it stable more easily. Maybe the EL7 version of libvirt with patches as necessary?
So, you asked "what version of libvirt do we need", but you still haven't actually given me any reasonable constraints; without that, I can't really answer the question. :-)
Are there any versions of libvirt designated "maintenance" releases by the community? Or is a release going to need to be "maintained" by whomever wants to keep them going (as RH will do with whatever version is in EL7)?
Well, I am taking a look now and the version currently in RHEL7 Beta is libvirt-1.1.1-<ver>.el7 ... the latest in Fedora land is 1.2.2 and the CentOS-6 version is 0.10.2-<ver>.el6.
I know that in the current xen4centos version of libvirt, we moved from the "EL6" 0.10.2 version to libvirt 0.10.2.<num> version to be able to leverage things written for that tree from other places and those new patches would not apply to the EL6 code because of backporting.
There are still updates being added to the 0.10.2-maint tree on the libvirt.org site, so if we pick any version we should still get some updates ... though obviously changing to a newer version after we stabilize might cause issues. So picking a version we can use and sticking to it is a good idea.
I guess if we pick any tree (like 1.1.1, 1.2.1, or 1.2.2) from the libvirt tree and stay in that branch we can stabilize and likely still get security coverage. If we pick the EL7 version we will get the RH backporting policy and maintain compatibility between CentOS-6 and CentOS-7 .. but there is much less code or documentation available other than just getting the packages from Red Hat, as they cherry pick things to pull in from all the libvirt trees and there is no real git tree available, etc. We can see what is in the SRPMS and create our own tree, but the code completely different from the libvirt.org trees.
If we pick one of the libvirt trees from libvirt.org then we are likely going to be able to share work/code from other places that are leveraged against those trees ... if we pick the EL7 version we will have to develop our changes specifically to this project and the code will be very unique, but we will have tighter integration between CentOS-6 and CentOS-7. There is also the question of QEMU support and how to best marry that into libvirt, etc.
I am just trying to get the discussion going so we can pick a version of libvirt that everyone can use for the CentOS SIGs, so that we don't have a "one off" in our branch.
Looking at the ubuntu package search (http://packages.ubuntu.com/) for LTS (the latest I see currently being 12.04LTS), they seem to be using a 0.9.8 customized version of libvirt there. So, they do not seem to use the latest and greatest libvirt in their enterprise releases either. I am not a ubuntu numbering expert though, so I might be wrong :)
What I am looking for is basically what concept do we want to use at this point ... EL code or libvirt.org code. It seems we picked libvirt.org code before because of the need to bring in code from other places ... but we tried to stay as close as possible to the CentOS-6 tree too so that people could, for example, use virt-manager from a CentOS workstation to connect to the Xen Dom0 sever and control it using libvirt. If we shift to libvirt-1.2.2, does that mean that we have to have people also update their non server machines they want to use to make connections for Dom0 control (or require a bunch of X on the Dom0 server to be able to use a GUI virt-manager via X, etc).
Does this explain more of what I think we need to work out?
I'll do a more thorough response later, but two thoughts real quick (see below)
On Thu, Mar 20, 2014 at 4:22 PM, Johnny Hughes johnny@centos.org wrote:
Looking at the ubuntu package search (http://packages.ubuntu.com/) for LTS (the latest I see currently being 12.04LTS), they seem to be using a 0.9.8 customized version of libvirt there. So, they do not seem to use the latest and greatest libvirt in their enterprise releases either. I am not a ubuntu numbering expert though, so I might be wrong :)
12.04 LTS came out two years ago now. :-) The 14.04 beta (which I believe will also be an LTS) has the latest libvirt (I think 1.2.2), and may manage to pull in 1.2.3 before it actually ships.
I don't think there's any point in having a libvirt driver without libxl support.
Does this explain more of what I think we need to work out?
Yes I think so, thanks!
-George
On Thu, Mar 20, 2014 at 4:22 PM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 05:03 PM, George Dunlap wrote:
On Wed, Mar 19, 2014 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
On 03/13/2014 12:04 PM, George Dunlap wrote:
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote:
<snip> > I get a forbidden on that SRPM ... do you have a copy somewhere? > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm
-- Pasi
OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
[CC'ing Dario Faggioli and Jim Fehlig, who have been working on libvirt on libxl]
libxl is designed to be backwards compatible, so there are a number of potential libvirt versions that should all work.
What kinds of constraints are there from the CentOS side? i.e., why not just use the most recent release?
The only issue with that is then we have to keep moving up to the latest version all the time ... not very "enterprisey". If we can pick a version with long term maintenance, we should be able to keep it stable more easily. Maybe the EL7 version of libvirt with patches as necessary?
So, you asked "what version of libvirt do we need", but you still haven't actually given me any reasonable constraints; without that, I can't really answer the question. :-)
Are there any versions of libvirt designated "maintenance" releases by the community? Or is a release going to need to be "maintained" by whomever wants to keep them going (as RH will do with whatever version is in EL7)?
Well, I am taking a look now and the version currently in RHEL7 Beta is libvirt-1.1.1-<ver>.el7 ... the latest in Fedora land is 1.2.2 and the CentOS-6 version is 0.10.2-<ver>.el6.
I know that in the current xen4centos version of libvirt, we moved from the "EL6" 0.10.2 version to libvirt 0.10.2.<num> version to be able to leverage things written for that tree from other places and those new patches would not apply to the EL6 code because of backporting.
There are still updates being added to the 0.10.2-maint tree on the libvirt.org site, so if we pick any version we should still get some updates ... though obviously changing to a newer version after we stabilize might cause issues. So picking a version we can use and sticking to it is a good idea.
I guess if we pick any tree (like 1.1.1, 1.2.1, or 1.2.2) from the libvirt tree and stay in that branch we can stabilize and likely still get security coverage. If we pick the EL7 version we will get the RH backporting policy and maintain compatibility between CentOS-6 and CentOS-7 .. but there is much less code or documentation available other than just getting the packages from Red Hat, as they cherry pick things to pull in from all the libvirt trees and there is no real git tree available, etc. We can see what is in the SRPMS and create our own tree, but the code completely different from the libvirt.org trees.
If we pick one of the libvirt trees from libvirt.org then we are likely going to be able to share work/code from other places that are leveraged against those trees ... if we pick the EL7 version we will have to develop our changes specifically to this project and the code will be very unique, but we will have tighter integration between CentOS-6 and CentOS-7. There is also the question of QEMU support and how to best marry that into libvirt, etc.
I am just trying to get the discussion going so we can pick a version of libvirt that everyone can use for the CentOS SIGs, so that we don't have a "one off" in our branch.
Looking at the ubuntu package search (http://packages.ubuntu.com/) for LTS (the latest I see currently being 12.04LTS), they seem to be using a 0.9.8 customized version of libvirt there. So, they do not seem to use the latest and greatest libvirt in their enterprise releases either. I am not a ubuntu numbering expert though, so I might be wrong :)
What I am looking for is basically what concept do we want to use at this point ... EL code or libvirt.org code. It seems we picked libvirt.org code before because of the need to bring in code from other places ... but we tried to stay as close as possible to the CentOS-6 tree too so that people could, for example, use virt-manager from a CentOS workstation to connect to the Xen Dom0 sever and control it using libvirt. If we shift to libvirt-1.2.2, does that mean that we have to have people also update their non server machines they want to use to make connections for Dom0 control (or require a bunch of X on the Dom0 server to be able to use a GUI virt-manager via X, etc).
Does this explain more of what I think we need to work out?
So by "libvirt.org" code you mean "upstream libvirt", as opposed to the EL version? Or are you trying to avoid the use of the word "upstream" because EL is also "upstream" of CentOS?
According to the libvirt.org download page:
"These maintenance branches should only contain bug fixes, and no new features, backported from the master branch, and are supported as long as at least one downstream distribution expresses interest in a given branch."
The "maintenance release" pages don't have all releases, just a handful of them. If we went with a libvirt.org tree, we should probably coordinate with the libvirt project as to which release would be best for us to standardize on. It seems likely that whatever version of libvirt Ubuntu 14.04 is using will end up being a maintenance release; choosing that one, if it's suitable, would mean less maintenance work for libvirt upstream (resulting, hopefully, in the tree being better maintained).
Re compatibility, I thought one of the whole points of libvirt was to allow this kind of backwards compatibility. We should obviously do some basic smoke testing, but it would be a major fail for libvirt's mission if an application compiled against 0.10 couldn't talk to a libvirt running 1.2.3.
Jim, do you know what the official policy is (if any) of different versions of libvirt talking to each other?
I don't know what consuming the EL libvirt would really be like, as I don't have any experience with that. But overall it seems like the best features would be if we consumed libvirt from libvirt.org, and that security and bug fixes would be acceptable, particularly if we shared a maintenance release with Ubuntu. If, as I expect, being a different libvirt version doesn't cause compatibility issues, I think we should probably just go with a libvirt.org tree.
-George
On 03/25/2014 11:23 AM, George Dunlap wrote:
On Thu, Mar 20, 2014 at 4:22 PM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 05:03 PM, George Dunlap wrote:
On Wed, Mar 19, 2014 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
On 03/13/2014 12:04 PM, George Dunlap wrote:
On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote: > <snip> >> I get a forbidden on that SRPM ... do you have a copy somewhere? >> > Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm > > -- Pasi OK, lets start making some decisions on what we want to try to use from a dependency perspective.
What version of libvirt do we need with this?
[CC'ing Dario Faggioli and Jim Fehlig, who have been working on libvirt on libxl]
libxl is designed to be backwards compatible, so there are a number of potential libvirt versions that should all work.
What kinds of constraints are there from the CentOS side? i.e., why not just use the most recent release?
The only issue with that is then we have to keep moving up to the latest version all the time ... not very "enterprisey". If we can pick a version with long term maintenance, we should be able to keep it stable more easily. Maybe the EL7 version of libvirt with patches as necessary?
So, you asked "what version of libvirt do we need", but you still haven't actually given me any reasonable constraints; without that, I can't really answer the question. :-)
Are there any versions of libvirt designated "maintenance" releases by the community? Or is a release going to need to be "maintained" by whomever wants to keep them going (as RH will do with whatever version is in EL7)?
Well, I am taking a look now and the version currently in RHEL7 Beta is libvirt-1.1.1-<ver>.el7 ... the latest in Fedora land is 1.2.2 and the CentOS-6 version is 0.10.2-<ver>.el6.
I know that in the current xen4centos version of libvirt, we moved from the "EL6" 0.10.2 version to libvirt 0.10.2.<num> version to be able to leverage things written for that tree from other places and those new patches would not apply to the EL6 code because of backporting.
There are still updates being added to the 0.10.2-maint tree on the libvirt.org site, so if we pick any version we should still get some updates ... though obviously changing to a newer version after we stabilize might cause issues. So picking a version we can use and sticking to it is a good idea.
I guess if we pick any tree (like 1.1.1, 1.2.1, or 1.2.2) from the libvirt tree and stay in that branch we can stabilize and likely still get security coverage. If we pick the EL7 version we will get the RH backporting policy and maintain compatibility between CentOS-6 and CentOS-7 .. but there is much less code or documentation available other than just getting the packages from Red Hat, as they cherry pick things to pull in from all the libvirt trees and there is no real git tree available, etc. We can see what is in the SRPMS and create our own tree, but the code completely different from the libvirt.org trees.
If we pick one of the libvirt trees from libvirt.org then we are likely going to be able to share work/code from other places that are leveraged against those trees ... if we pick the EL7 version we will have to develop our changes specifically to this project and the code will be very unique, but we will have tighter integration between CentOS-6 and CentOS-7. There is also the question of QEMU support and how to best marry that into libvirt, etc.
I am just trying to get the discussion going so we can pick a version of libvirt that everyone can use for the CentOS SIGs, so that we don't have a "one off" in our branch.
Looking at the ubuntu package search (http://packages.ubuntu.com/) for LTS (the latest I see currently being 12.04LTS), they seem to be using a 0.9.8 customized version of libvirt there. So, they do not seem to use the latest and greatest libvirt in their enterprise releases either. I am not a ubuntu numbering expert though, so I might be wrong :)
What I am looking for is basically what concept do we want to use at this point ... EL code or libvirt.org code. It seems we picked libvirt.org code before because of the need to bring in code from other places ... but we tried to stay as close as possible to the CentOS-6 tree too so that people could, for example, use virt-manager from a CentOS workstation to connect to the Xen Dom0 sever and control it using libvirt. If we shift to libvirt-1.2.2, does that mean that we have to have people also update their non server machines they want to use to make connections for Dom0 control (or require a bunch of X on the Dom0 server to be able to use a GUI virt-manager via X, etc).
Does this explain more of what I think we need to work out?
So by "libvirt.org" code you mean "upstream libvirt", as opposed to the EL version? Or are you trying to avoid the use of the word "upstream" because EL is also "upstream" of CentOS?
According to the libvirt.org download page:
"These maintenance branches should only contain bug fixes, and no new features, backported from the master branch, and are supported as long as at least one downstream distribution expresses interest in a given branch."
The "maintenance release" pages don't have all releases, just a handful of them. If we went with a libvirt.org tree, we should probably coordinate with the libvirt project as to which release would be best for us to standardize on. It seems likely that whatever version of libvirt Ubuntu 14.04 is using will end up being a maintenance release; choosing that one, if it's suitable, would mean less maintenance work for libvirt upstream (resulting, hopefully, in the tree being better maintained).
Re compatibility, I thought one of the whole points of libvirt was to allow this kind of backwards compatibility. We should obviously do some basic smoke testing, but it would be a major fail for libvirt's mission if an application compiled against 0.10 couldn't talk to a libvirt running 1.2.3.
Jim, do you know what the official policy is (if any) of different versions of libvirt talking to each other?
I don't know what consuming the EL libvirt would really be like, as I don't have any experience with that. But overall it seems like the best features would be if we consumed libvirt from libvirt.org, and that security and bug fixes would be acceptable, particularly if we shared a maintenance release with Ubuntu. If, as I expect, being a different libvirt version doesn't cause compatibility issues, I think we should probably just go with a libvirt.org tree.
-George
Yes, I meant a libvirt.org tree by upstream.
I also think this would be the best option as well.
I do see that CVE updates have been rolled into the maintenance branches even the 0.9.x version.
So we can stablize on the same branch as Ubuntu 14.04 LTS ... that would be fine with me if it has what we want.
On mar, 2014-03-11 at 10:01 +0200, Pasi Kärkkäinen wrote:
Fedora has rpms at least for 4.4.0-rc4, not sure about the rc5/rc6 or the final..
Probably not, as those were produced for TestDays, and we did not have a TestDay for rc5 or rc6 (the changes were not worth one).
If you want to be sure, I can ask the Fedora maintainer, though.
but I don't think the .spec file really needs to change between rc4 and the final.
FWIW, me neither.
Regards, Dario
On mar, 2014-02-18 at 19:19 +0000, Karanbir Singh wrote:
On 02/18/2014 04:43 PM, Pasi Kärkkäinen wrote:
- After updating to Xen 4.3.2 rpms start troubleshooting/debugging the libvirt libxl driver and get it working with Xen4Centos6 system..
I believe Dario Faggioli has some of this ironed out already.
Well, I'm using and trying to test regularly it on Fedora, I can certainly do something similar in/for CentOS.
As discussing with KB in Brussels, if the libvirt version is not a problem (i.e., we can pickup whichever we like, with strong preference for something 'as trunk as possible'), the libxl driver is not that bad.
The biggest missing features are migration and PCI passthrough.
Migration, I'd have o double check. I haven't seen the patches in a while, but I've had issues with my subscription to the libvir list, so there may be things I don't know (I'll investigate and report back).
Passthrough, it's not in, and this is the latest submission of the patch series: http://comments.gmane.org/gmane.comp.emulators.libvirt/92935 It's not far from getting merged, but it won't make it for next version of libvirt (which I think is going to be released at the end of February).
That means, most likely, if you want PCI passthrough in your CentOS' libvirt, we'll have to carry the patches... which does not seem terrible to me, is it?
Dario are you on the centos-virt list ?
I am now. :-)
Regards, Dario
-
Dario Faggioli -
David Vrabel -
George Dunlap -
Johnny Hughes -
Karanbir Singh -
Pasi Kärkkäinen