[lago-devel] Why do we need qemu-kvm-*ev* ?

[Nadav Goldin]

>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 at redhat.com> wrote:
>
>
> On Thu, Mar 16, 2017 at 2:37 PM, Eyal Edri <eedri at 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 at redhat.com> wrote:
>>>
>>>
>>>
>>> On Mar 16, 2017 1:40 PM, "Eyal Edri" <eedri at redhat.com> wrote:
>>>
>>>
>>>
>>> On Thu, Mar 9, 2017 at 6:08 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Mar 9, 2017 at 1:51 PM Nadav Goldin <ngoldin at 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 at redhat.com>
>>>>> wrote:
>>>>> > On 9 March 2017 at 11:12, Yaniv Kaul <ykaul at 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 at redhat.com
>>>>> > RHCE, RHCi, RHV-DevOps Team
>>>>> > https://ifireball.wordpress.com/
>>>>> > _______________________________________________
>>>>> > lago-devel mailing list
>>>>> > lago-devel at ovirt.org
>>>>> > http://lists.ovirt.org/mailman/listinfo/lago-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> lago-devel mailing list
>>>> lago-devel at 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)
>
>