[opensuse-cloud] C:O:M not working with Xen on SLES11 SP2 because of libvirt 0.9.6
With the change https://review.openstack.org/#/c/19624/ the type of disk images is again tap:raw (instead of file:raw), because file:raw was not working for qcow2 images. At the moment SLES11 SP2 provides libvirt 0.9.6, resulting in the following error at the moment: 09:46:34.392: 3981: error : xend_post:416 : POST operation failed: xend_post: error from xen daemon: (xend.err 'Error creating domain: Invalid Configuration: tap:raw not a valid disk type') Yufang Zhang wrote, that newer libvirt version work without problems using tap:raw instead of file:raw. I tested with libvirt 1.0.3 (from virtualization) and had no problems using tap:raw instead of file:raw. Result: libvirt 0.9.6 is not working with C:O:M when using Xen. I suggest adding libvirt 1.0.3 from virtualization to the C:O:M repository to be able to use Xen on SLES11 SP2. Christian. -- Christian Berendt Cloud Computing Solution Architect Tel.: +49-171-5542175 Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
2013/3/14 Christian Berendt
At the moment SLES11 SP2 provides libvirt 0.9.6, resulting in the following error at the moment:
09:46:34.392: 3981: error : xend_post:416 : POST operation failed: xend_post: error from xen daemon: (xend.err 'Error creating domain: Invalid Configuration: tap:raw not a valid disk type')
Yufang Zhang wrote, that newer libvirt version work without problems using tap:raw instead of file:raw.
I tested with libvirt 1.0.3 (from virtualization) and had no problems using tap:raw instead of file:raw.
Result: libvirt 0.9.6 is not working with C:O:M when using Xen.
I suggest adding libvirt 1.0.3 from virtualization to the C:O:M repository to be able to use Xen on SLES11 SP2.
Thats a bit of a problem, we don't really want to overlay packages from SLES on 11 SP2. I think this is an important problem though that we need to tackle in a way. Would you mind creating a bugreport? Thanks, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 03/14/2013 10:47 AM, Dirk Müller wrote:
Would you mind creating a bugreport?
For OpenStack? We already had one. But tap:raw is the correct way, it's working with libvirt 1.0.3. So the issue is in libvirt 0.9.6 and not in OpenStack itself. Christian. -- Christian Berendt Cloud Computing Solution Architect Tel.: +49-171-5542175 Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
2013/3/14 Christian Berendt
For OpenStack? We already had one. But tap:raw is the correct way, it's working with libvirt 1.0.3. So the issue is in libvirt 0.9.6 and not in OpenStack itself.
Hi Christian, I meant a bugreport for novell (bugzilla.novell.com). I think we need to evaluate if it can be fixed in the SLE libvirt package without a version update as well. the "we" in this case was the SUSE Cloud team. if "SUSE Cloud" is continue to support Xen, then we need to solve the issue without a package overlay. either by upgrading libvirt, by fixing the old libvirt or by somehow adding a kludge to our openstack packages. Which way is the best needs to be investigated first. On the bright side I can see that we are going to have the newer libvirt already in SLE11 SP3, so this is a SP2 specific problem for now. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 03/14/2013 12:49 PM, Dirk Müller wrote:
the "we" in this case was the SUSE Cloud team. if "SUSE Cloud" is continue to support Xen, then we need to solve the issue without a package overlay. either by upgrading libvirt, by fixing the old libvirt or by somehow adding a kludge to our openstack packages. Which way is the best needs to be investigated first.
I thought SUSE Cloud will live in a subproject in the ISV project and _not_ in C:O? I don't like that we have to do things, because there are requirement of the SUSE Cloud. And I don't like that we can't simply provide a newer libvirt package because a requirement of the SUSE Cloud is to not overlay existing packages in SLE. Also I don't like it to add patches to the packages in C:O only to workaround issues in the SUSE Cloud existing because of some requirements of the SUSE Cloud. If a newer libvirt package is a problem for the SUSE Cloud you can simply remove the libvirt package in the SUSE Cloud repository (in the ISV project) and add needed patches to workaround existing issues there. But using workarounds to support older versions of libvirt or creating bugreports for SLE to backport bugfixes to 0.9.6 (when SLES11 SP3 will provide a newer version of libvirt..) is not the way I want to go. It's nice that SLES11 SP3 will include a newer libvirt package, but we need the newer libvirt now and not in a few months. We should clarify how to proceed with such issues in C:O. In my understanding: C:O != SUSE Cloud. Christian. -- Christian Berendt Cloud Computing Solution Architect Tel.: +49-171-5542175 Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
2013/3/14 Christian Berendt
I don't like that we have to do things, because there are requirement of the SUSE Cloud. And I don't like that we can't simply provide a newer libvirt package because a requirement of the SUSE Cloud is to not overlay existing packages in SLE. Also I don't like it to add patches to the packages in C:O only to workaround issues in the SUSE Cloud existing because of some requirements of the SUSE Cloud.
Hi, I generally agree. However, also generally, we should be nice to the underlying platform. Be it because of SUSE Cloud or because of Cloud:OpenStack:Grizzly. For the same reason we wouldn't put a linux 3.9.rc4 kernel into C:O:G just because it fixes one particular problem we have with grizzly on the platform. If there is a specific problem, we need to find a specific solution. The specific solution might very well be "well, its not worth spending the effort fixing it in the old version of libvirt", and then the specific solution is to replace libvirt with a newer release. I'm very much fine with that and I'm very happy that you're spending time on doing that and discussing it here. The part I have resentiments with is that without _understanding_ the issue going with a newer version. If you understood the issue (aka can point out the missing patch in the old libvirt package or give a document/testcase/reproducer/problem description) then I'm fine with following the resolution of doing a version upgrade. I just didn't have the impression that we have reached that point yet, but maybe I'M the one missing the background information. Could you please help me out here? Is there a bugzilla report or anything that sheds further light on the problem that you fixed with the upgrade? Thanks, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 03/14/2013 10:47 AM, Dirk Müller wrote:
Thats a bit of a problem, we don't really want to overlay packages from SLES on 11 SP2. I think this is an important problem though that we need to tackle in a way.
Adding a newer libvirt to C:O:M is the best way to solve the issue. OpenStack often needs newer software then delivered with SLE. Everyone who don't want to use a newer libvirt can lock the packages in libzypp. I think it's not good to workaround using patches in our packages to support older software version. This way we'll become very dirty packages. We don't have a bug in OpenStack, we have an outdated libvirt in SLE.
we don't really want to overlay packages from SLES on 11 SP2
Who is "we"? I have no problem with overlaying packages when it's necessary to support Xen. Christian. -- Christian Berendt Cloud Computing Solution Architect Tel.: +49-171-5542175 Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 03/14/2013 11:34 AM, Christian Berendt wrote:
On 03/14/2013 10:47 AM, Dirk Müller wrote:
Thats a bit of a problem, we don't really want to overlay packages from SLES on 11 SP2. I think this is an important problem though that we need to tackle in a way.
Adding a newer libvirt to C:O:M is the best way to solve the issue.
OpenStack often needs newer software then delivered with SLE. Everyone who don't want to use a newer libvirt can lock the packages in libzypp. I think it's not good to workaround using patches in our packages to support older software version. This way we'll become very dirty packages.
I somewhat agree here, Cloud:OpenStack:* should be useful on it's own. So I linked libvirt. Altough it will therefore end up in isv:SUSE:Cloud:2.0, that doesn't imply this particular libvirt package will end up on any Cloud-2.0 media.
We don't have a bug in OpenStack, we have an outdated libvirt in SLE.
we don't really want to overlay packages from SLES on 11 SP2
Who is "we"? I have no problem with overlaying packages when it's necessary to support Xen.
Christian.
-- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
participants (3)
-
Christian Berendt -
Dirk Müller -
Sascha Peilicke