I don't see a good reason why we need anything but qemu-kvm. The following commit adds the requirement - but I don't see the real need for it: commit a7d71ad2994aab3234371e850c617b826b3681b1 Author: Rafael Martins <rmartins@redhat.com> Date: Tue Jan 3 15:26:54 2017 +0100 Force usage of qemu-kvm-rhev on centos/rhel Lago requires qemu-kvm >= 2.1.2, these are the required package names for each distro: CentOS: the package is named 'qemu-kvm-ev', but it provides 'qemu-kvm-rhev' RHEL: named 'qemu-kvm-rhev' Fedora: 'qemu-kvm' Signed-off-by: gbenhaim <galbh2@gmail.com> Signed-off-by: Nadav Goldin <ngoldin@redhat.com>
On 9 March 2017 at 09:38, Yaniv Kaul <ykaul@redhat.com> wrote:
I don't see a good reason why we need anything but qemu-kvm. The following commit adds the requirement - but I don't see the real need for it:
The last time I check Lago simply does not work with out it. Also I seem to remember that back when Lago was called STF, snapshots did not work or qemu-kvm. But maybe that has changed by now. Why does *-ev exist at all? Could it be consolidated with the non *-ev packages some day? -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On Thu, Mar 9, 2017, 10:08 AM Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 09:38, Yaniv Kaul <ykaul@redhat.com> wrote:
I don't see a good reason why we need anything but qemu-kvm. The following commit adds the requirement - but I don't see the real need for it:
The last time I check Lago simply does not work with out it.
Very surprising. Can't think of a good reason why.
Also I seem to remember that back when Lago was called STF, snapshots did not work or qemu-kvm. But maybe that has changed by now.
Why does *-ev exist at all? Could it be consolidated with the non *-ev packages some day?
Let's not go there... Y.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day... -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
Very surprising. Can't think of a good reason why.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find,
with qemu-kvm-1.5.3-126.el7.x86_64: libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU I guess snapshots might be another problem, though never tested it. though its not really complete. [1] https://lists.centos.org/pipermail/centos-virt/2015-October/004717.html On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
with qemu-kvm-1.5.3-126.el7.x86_64:
libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU
Ah, my fault for adding iothreads. We could remove them (they don't add more than a small performance improvement, hardly noticeable most likely) if it makes deployment harder. Y.
I guess snapshots might be another problem, though never tested it.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find, though its not really complete.
[1] https://lists.centos.org/pipermail/centos-virt/2015-October/004717.html
On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
On Thu, Mar 9, 2017 at 6:08 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
with qemu-kvm-1.5.3-126.el7.x86_64:
libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU
Ah, my fault for adding iothreads. We could remove them (they don't add more than a small performance improvement, hardly noticeable most likely) if it makes deployment harder.
Can you send a patch to remove it or open an issue? If we can drop the -ev requirement it will ease the demo tool installation as well.
Y.
I guess snapshots might be another problem, though never tested it.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find, though its not really complete.
[1] https://lists.centos.org/pipermail/centos-virt/2015- October/004717.html
On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
On Mar 16, 2017 1:40 PM, "Eyal Edri" <eedri@redhat.com> wrote: On Thu, Mar 9, 2017 at 6:08 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
with qemu-kvm-1.5.3-126.el7.x86_64:
libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU
Ah, my fault for adding iothreads. We could remove them (they don't add more than a small performance improvement, hardly noticeable most likely) if it makes deployment harder.
Can you send a patch to remove it or open an issue? If we can drop the -ev requirement it will ease the demo tool installation as well. B Sure, but is that the only -ev feature we use? Y.
Y.
I guess snapshots might be another problem, though never tested it.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find, though its not really complete.
[1] https://lists.centos.org/pipermail/centos-virt/2015-October/ 004717.html
On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 <+972%209-769-2018> irc: eedri (on #tlv #rhev-dev #rhev-integ)
We can build Lago unstable w/o it and run OST on the manual job to verify none of the tests use it. On Thu, Mar 16, 2017 at 2:03 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Mar 16, 2017 1:40 PM, "Eyal Edri" <eedri@redhat.com> wrote:
On Thu, Mar 9, 2017 at 6:08 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
with qemu-kvm-1.5.3-126.el7.x86_64:
libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU
Ah, my fault for adding iothreads. We could remove them (they don't add more than a small performance improvement, hardly noticeable most likely) if it makes deployment harder.
Can you send a patch to remove it or open an issue? If we can drop the -ev requirement it will ease the demo tool installation as well.
B Sure, but is that the only -ev feature we use? Y.
Y.
I guess snapshots might be another problem, though never tested it.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find, though its not really complete.
[1] https://lists.centos.org/pipermail/centos-virt/2015-October/ 004717.html
On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel
phone: +972-9-7692018 <+972%209-769-2018> irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
On Thu, Mar 16, 2017 at 2:37 PM, Eyal Edri <eedri@redhat.com> wrote:
We can build Lago unstable w/o it and run OST on the manual job to verify none of the tests use it.
The tests are not the issue - it's the L0 qemu-kvm - the way Lago itself uses qemu-kvm. I'd like to ensure we don't shoot ourselves in the foot by not using it - I assume not. I'll see if I can get this data from libvirt's 'capabilities', if not, I'll drop it and we'll see how it goes. It's not like it's a huge performance win right now. Y.
On Thu, Mar 16, 2017 at 2:03 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Mar 16, 2017 1:40 PM, "Eyal Edri" <eedri@redhat.com> wrote:
On Thu, Mar 9, 2017 at 6:08 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
with qemu-kvm-1.5.3-126.el7.x86_64:
libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU
Ah, my fault for adding iothreads. We could remove them (they don't add more than a small performance improvement, hardly noticeable most likely) if it makes deployment harder.
Can you send a patch to remove it or open an issue? If we can drop the -ev requirement it will ease the demo tool installation as well.
B Sure, but is that the only -ev feature we use? Y.
Y.
I guess snapshots might be another problem, though never tested it.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find, though its not really complete.
[1] https://lists.centos.org/pipermail/centos-virt/2015-October/ 004717.html
On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel
phone: +972-9-7692018 <+972%209-769-2018> irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel
phone: +972-9-7692018 <+972%209-769-2018> irc: eedri (on #tlv #rhev-dev #rhev-integ)
From what I understand: qemu-kvm exists for backward compatibility, new features will usually hit qemu-kvm-ev.
If my understanding is correct(couldn't find any official doc to confirm), I think we should stick with 'qemu-kvm-ev'. Even if we don't hit a issue now, we could hit something else in the future. I don't think it complicates the installation, its just another repository/channel, like all others which we require. It is covered pretty well both upstream and downstream. Another option is to add 'recommends' for 'qemu-kvm-ev' in the spec file, and require 'qemu-kvm'. Code wise we could detect the installed QEMU version, and toggle the needed features(which for now might only be iothreads). On Thu, Mar 16, 2017 at 3:00 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 16, 2017 at 2:37 PM, Eyal Edri <eedri@redhat.com> wrote:
We can build Lago unstable w/o it and run OST on the manual job to verify none of the tests use it.
The tests are not the issue - it's the L0 qemu-kvm - the way Lago itself uses qemu-kvm. I'd like to ensure we don't shoot ourselves in the foot by not using it - I assume not. I'll see if I can get this data from libvirt's 'capabilities', if not, I'll drop it and we'll see how it goes. It's not like it's a huge performance win right now. Y.
On Thu, Mar 16, 2017 at 2:03 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Mar 16, 2017 1:40 PM, "Eyal Edri" <eedri@redhat.com> wrote:
On Thu, Mar 9, 2017 at 6:08 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin@redhat.com> wrote:
Very surprising. Can't think of a good reason why.
with qemu-kvm-1.5.3-126.el7.x86_64:
libvirt: QEMU Driver error : unsupported configuration: IOThreads not supported for this QEMU
Ah, my fault for adding iothreads. We could remove them (they don't add more than a small performance improvement, hardly noticeable most likely) if it makes deployment harder.
Can you send a patch to remove it or open an issue? If we can drop the -ev requirement it will ease the demo tool installation as well.
B Sure, but is that the only -ev feature we use? Y.
Y.
I guess snapshots might be another problem, though never tested it.
From what I understand, new features are not always backported to the 'plain' 'qemu-kvm'. This[1] was the best explanation I could find, though its not really complete.
[1] https://lists.centos.org/pipermail/centos-virt/2015-October/004717.html
On Thu, Mar 9, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 9 March 2017 at 11:12, Yaniv Kaul <ykaul@redhat.com> wrote: > > Very surprising. Can't think of a good reason why. > You are welcome to try and either prove me wrong, or find the reason (And potentially fix it...) Alternatively open a Lago issue and we'll get to it some day...
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel
phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel
phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
participants (4)
-
Barak Korren -
Eyal Edri -
Nadav Goldin -
Yaniv Kaul