Thank you all for your feedback, I moved the feature to implementation status. Patches: - engine http://gerrit.ovirt.org/#/c/9753/ - vdsm: http://gerrit.ovirt.org/#/c/9507/ (engine patch is built on this) - or alternative vdsm: http://gerrit.ovirt.org/#/c/9367/ (vdsm guys still need to decide which one do they want) ----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: snmishra@linux.vnet.ibm.com Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 5, 2012 9:56:02 PM Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 09:15 PM, snmishra@linux.vnet.ibm.com wrote:
Quoting Doron Fediuck <dfediuck@redhat.com>:
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 5, 2012 7:14:46 PM Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "Laszlo Hornyak" <lhornyak@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 5, 2012 6:10:55 PM Subject: Re: [Engine-devel] host cpu feature
Alternative idea, inspired by "Thus, if you hit any bugs, you are on your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt 'host-passthrough'): A config option to determine if we use host-model or host-passthrough. Y.
I do not think the engine should go to this level. ie- it can ask for passthrough as a feature, and the actual implementation is handled by vdsm.
If vdsm decides over host-passthrough or host-model, then how will the engine user know what exactly his VM gets. I think vdsm must be told exactly what to do.
VDSM maintains some level of independence. This is why it the engine should be able to ask for passthrough as a feature. Otherwize vdsm will handle it. So for now I suggest we stick to passthrough only, and if we get an RFE for advanced mode we'll support the host model.
What are we gaining by using passthrough over host-model? Looking at libvirt documentation, it seems that both modes give host CPU capabilities to guest VM. Whereas the downside of passthrough is that it limits migration. Whereas host-model will migrate to other hardware and if the destination hardware is better than source then the guest VM performance can be improved by rebooting guest.
As a stretch goal, ovirt can keep track of host capabilities and inform the user after migrating to a better host, that a reboot may improve guest performance.
pass-through may give better performance. host-model would be relevant when we can support live migration inside the cluster for some of the nodes, which will be relevant when the scheduler is more pluggable/extendable than today. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel