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?

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.

hopefully not relevant any more, but need to validate won't break older engines indeed.