On Wed, Mar 13, 2013 at 12:58:44AM +0200, Itamar Heim wrote:
On 03/12/2013 05:07 PM, Dan Kenigsberg wrote:
>On Tue, Mar 12, 2013 at 10:37:41AM -0400, Laszlo Hornyak wrote:
>>Hi,
>>
>>I came across a VmDynamic property 'kvm_enable'. It sounds strange for
me, because ovirt is very colsely integrated with kvm. So a short dig into this flag...
>>There is a similar thing for the VDS, it is set to true by vdsm is the host CPU
has a VT flag. It is actually used to check if the host is OK to run VMS.
>>
>>But the one for Vm it looks like a distributed logical loop in vdsm: it is set
when constructing a VM object (vdsm/vm.py:~343) from the data sent by the client (engine)
and then reported back in vm stats, so it is just a roundtrip between vdsm and it's
client.
>>In the engine side, it is just keeps sending it between the frontend DB and vdsm,
never part of a decision.
>>
>>Is this still needed here? Can I remove?
>>VDSM guys?
>
>I have a vague memeory that once upon at time, qemu occasionally failed
>to enable kvm support - even though it was asked to. I then silently
>switched to emulated mode, which was grindingly slow. Engine wanted to
>know about such occasions.
>
>I believe that a better technical approach would have been to kill the
>violating process, and not let it run at all (unless qemu emulation was
>strictly requested by management).
>
>Anyway, as you have noted, this has rotten away throuh the years, and
>unless older Engine versions are expecting this value in any way, I am
>all for dropping it.
I think this was about something else - the kvmEnable flag was used
to launch installations of guests not correctly supported by kvm
that required real mode or something like that.
You are now speaking about kvmEnable sent by Engine to Vdsm. Laszlo was
speaking about a supposedly-dynamically-changing kvmEnable that is
reported back, in getVmStats.
hopefully not relevant any more, but need to validate won't
break
older engines indeed.