Update on QEMU Snapshot Package in CentOS
All: I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG. He has expressed concerns that if oVirt curates the qemu package in order to have the snapshotting flag turned on, then there might arise a situation where each project within the SIG would be getting their own versions of qemu. To help mitigate against such an occurrence, KB suggested that oVirt take ownership of not the RHEL distro-specific version of qemu, but a more upstream version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed to make more sense to keep downloading from CentOS repo and rebuilding it with flag enabled and either sharing that with the SIG or inside our own oVirt repository. Basically, KB's issue that if oVirt does wish to curate this package on behalf of the SIG, that we as a project would be willing to manage all requests from the rest of the SIG participants (such as the example he raised, which was his personal wish that the vdi and Microsoft vpc formats be turned on as well, so he can build Azure images more easily). If we were willing to take on such a responsibility for the SIG, then this would mitigate multiple versions of qemu appearing.
From my side, I believe this is a reasonable expectation, given that we are going to get what we need within CentOS and still can be a responsible community player within the SIG.
I put the question to the developers: is this something we want to undertake, or should we simply maintain our version of qemu within an oVirt-specific repository? Peace, Brian -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC
Hi, well the best way would be, if this flag could get introduced in the plain EL6 and EL7 Upstreams of CentOS so CentOS would just consume them. Is there any reason inside redhat this flag is only in the qemu-kvm package for rhev but not in the qemu-kvm for rhel? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On Tue, Jun 17, 2014 at 02:56:49PM -0400, Brian Proffitt wrote:
All:
I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG. He has expressed concerns that if oVirt curates the qemu package in order to have the snapshotting flag turned on, then there might arise a situation where each project within the SIG would be getting their own versions of qemu.
To help mitigate against such an occurrence, KB suggested that oVirt take ownership of not the RHEL distro-specific version of qemu, but a more upstream version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed to make more sense to keep downloading from CentOS repo and rebuilding it with flag enabled and either sharing that with the SIG or inside our own oVirt repository.
Basically, KB's issue that if oVirt does wish to curate this package on behalf of the SIG, that we as a project would be willing to manage all requests from the rest of the SIG participants (such as the example he raised, which was his personal wish that the vdi and Microsoft vpc formats be turned on as well, so he can build Azure images more easily). If we were willing to take on such a responsibility for the SIG, then this would mitigate multiple versions of qemu appearing.
From my side, I believe this is a reasonable expectation, given that we are going to get what we need within CentOS and still can be a responsible community player within the SIG.
I put the question to the developers: is this something we want to undertake, or should we simply maintain our version of qemu within an oVirt-specific repository?
Personally I wonder why it's that important. With RHEL7 out and CentOS7 expected soonish, why not aim at supporting that. I'm sure that qemu is new enough to support snapshots.
Am 18.06.2014 09:36, schrieb Ewoud Kohl van Wijngaarden:
Personally I wonder why it's that important. With RHEL7 out and CentOS7 expected soonish, why not aim at supporting that. I'm sure that qemu is new enough to support snapshots.
Well I'm pretty sure it will take some time and testing until people roll out EL7. Furthermore who knows if this flag is available in EL7? There is no reason stated why it is turned off in EL6, so I fear it might just as well be turned off in EL7 for the same non-existent reason. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On 06/18/2014 10:36 AM, Ewoud Kohl van Wijngaarden wrote:
On Tue, Jun 17, 2014 at 02:56:49PM -0400, Brian Proffitt wrote:
All:
I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG. He has expressed concerns that if oVirt curates the qemu package in order to have the snapshotting flag turned on, then there might arise a situation where each project within the SIG would be getting their own versions of qemu.
To help mitigate against such an occurrence, KB suggested that oVirt take ownership of not the RHEL distro-specific version of qemu, but a more upstream version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed to make more sense to keep downloading from CentOS repo and rebuilding it with flag enabled and either sharing that with the SIG or inside our own oVirt repository.
Basically, KB's issue that if oVirt does wish to curate this package on behalf of the SIG, that we as a project would be willing to manage all requests from the rest of the SIG participants (such as the example he raised, which was his personal wish that the vdi and Microsoft vpc formats be turned on as well, so he can build Azure images more easily). If we were willing to take on such a responsibility for the SIG, then this would mitigate multiple versions of qemu appearing.
From my side, I believe this is a reasonable expectation, given that we are going to get what we need within CentOS and still can be a responsible community player within the SIG.
I put the question to the developers: is this something we want to undertake, or should we simply maintain our version of qemu within an oVirt-specific repository?
Personally I wonder why it's that important. With RHEL7 out and CentOS7 expected soonish, why not aim at supporting that. I'm sure that qemu is new enough to support snapshots.
its not about the version. these features are not supported in rhel7 qemu-kvm. they still need to be compiled with the extra flag.
Does the version with the extra flag break something in rhel7 or why is it not set at compile time? I really fail to understand this. Apparently you set this flag in rhev, but not in rhel. So it would be cool to get any reasons for this strange behavior. maybe scott herrold could explain this("Principal product manager, Virtualization, Red Hat" according to my information)? Am 18.06.2014 10:19, schrieb Itamar Heim:
its not about the version. these features are not supported in rhel7 qemu-kvm. they still need to be compiled with the extra flag.
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
----- Original Message -----
From: "Sven Kieske" <S.Kieske@mittwald.de> To: devel@ovirt.org, sherold@redhat.com Sent: Wednesday, June 18, 2014 4:30:09 AM Subject: Re: [ovirt-devel] Update on QEMU Snapshot Package in CentOS
Does the version with the extra flag break something in rhel7 or why is it not set at compile time?
I really fail to understand this. Apparently you set this flag in rhev, but not in rhel.
So it would be cool to get any reasons for this strange behavior. maybe scott herrold could explain this("Principal product manager, Virtualization, Red Hat" according to my information)?
We deliver a different QEMU in RHEL than is delivered in RHEV and RHEL-OSP. In RHEL 6 there's a different set of features at compile time. In RHEL 7.x you'll see us shipping different releases - eg. rebasing onto a new QEMU version in RHEV/RHEL-OSP which is something that's not possible within RHEL.
Am 18.06.2014 10:19, schrieb Itamar Heim:
its not about the version. these features are not supported in rhel7 qemu-kvm. they still need to be compiled with the extra flag.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Am 18.06.2014 11:03, schrieb Andrew Cathrow:
We deliver a different QEMU in RHEL than is delivered in RHEV and RHEL-OSP. In RHEL 6 there's a different set of features at compile time. In RHEL 7.x you'll see us shipping different releases - eg. rebasing onto a new QEMU version in RHEV/RHEL-OSP which is something that's not possible within RHEL.
Well thanks for the response but the only new information that you provide is that you will rebase qemu in rhev which "is not possible" in rhel 7. but I was asking for some kind of reasoning _why_ that's not possible _and_ additionally would like to point out that no rebasing at all is needed as it's just recompiling with one flag added. I begin to think this has something to do with marketing as there is apparently no technical reason to do this. Of course I know that you can not simply introduce a new version in rhel6, according to your update policy and your qa. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On 06/18/2014 05:16 AM, Sven Kieske wrote:
Am 18.06.2014 11:03, schrieb Andrew Cathrow:
We deliver a different QEMU in RHEL than is delivered in RHEV and RHEL-OSP. In RHEL 6 there's a different set of features at compile time. In RHEL 7.x you'll see us shipping different releases - eg. rebasing onto a new QEMU version in RHEV/RHEL-OSP which is something that's not possible within RHEL.
Well thanks for the response but the only new information that you provide is that you will rebase qemu in rhev which "is not possible" in rhel 7.
but I was asking for some kind of reasoning _why_ that's not possible _and_ additionally would like to point out that no rebasing at all is needed as it's just recompiling with one flag added.
I begin to think this has something to do with marketing as there is apparently no technical reason to do this.
No it's about productization - how do we monetize investments that we make. That's something that we need to consider as we have literally thousands of engineers who have to be paid.
Of course I know that you can not simply introduce a new version in rhel6, according to your update policy and your qa.
Thank you again for this clear response :) I just wonder why this wasn't mentioned earlier, as I can perfectly understand the reasoning. Am 18.06.2014 11:21, schrieb Andrew Cathrow:
No it's about productization - how do we monetize investments that we make. That's something that we need to consider as we have literally thousands of engineers who have to be paid.
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On 06/18/2014 05:24 AM, Sven Kieske wrote:
Thank you again for this clear response :) I just wonder why this wasn't mentioned earlier, as I can perfectly understand the reasoning.
It's certainly been discussed, but there are so many venues I lose track of what's been said where. Aic
Am 18.06.2014 11:21, schrieb Andrew Cathrow:
No it's about productization - how do we monetize investments that we make. That's something that we need to consider as we have literally thousands of engineers who have to be paid.
On 06/17/2014 09:56 PM, Brian Proffitt wrote:
All:
I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG. He has expressed concerns that if oVirt curates the qemu package in order to have the snapshotting flag turned on, then there might arise a situation where each project within the SIG would be getting their own versions of qemu.
we just want the 'rhel version as is, compiled with an extra flag'. if other groups the same srpm with other flags, i think should be ok (which is different than 'use a different srpm from head'.
To help mitigate against such an occurrence, KB suggested that oVirt take ownership of not the RHEL distro-specific version of qemu, but a more upstream version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed to make more sense to keep downloading from CentOS repo and rebuilding it with flag enabled and either sharing that with the SIG or inside our own oVirt repository.
Basically, KB's issue that if oVirt does wish to curate this package on behalf of the SIG, that we as a project would be willing to manage all requests from the rest of the SIG participants (such as the example he raised, which was his personal wish that the vdi and Microsoft vpc formats be turned on as well, so he can build Azure images more easily). If we were willing to take on such a responsibility for the SIG, then this would mitigate multiple versions of qemu appearing.
From my side, I believe this is a reasonable expectation, given that we are going to get what we need within CentOS and still can be a responsible community player within the SIG.
I put the question to the developers: is this something we want to undertake, or should we simply maintain our version of qemu within an oVirt-specific repository?
I see two variants here: 1. RHEL proper SRPM, where the only change is how its built wrt flags/configuration allowing more than what RHEL comes with out of the box (would cover vpc format if just a flag). will not cover special backports not going through rhel proper. 2. future/next/head/latest SRPM, based on an upstream qemu stable version rpm (or maybe the fedora virt-preview one is more likely). one would be 'stable', the other 'updates-testing' or 'virt-preview'.
participants (5)
-
Andrew Cathrow -
Brian Proffitt -
Ewoud Kohl van Wijngaarden -
Itamar Heim -
Sven Kieske