Quoting Doron Fediuck <[email protected]>:
----- Original Message -----
From: "Laszlo Hornyak" <[email protected]>
To: "Doron Fediuck" <[email protected]>
Cc: "engine-devel" <[email protected]>
Sent: Wednesday, December 5, 2012 7:14:46 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
> From: "Doron Fediuck" <[email protected]>
> To: "Yaniv Kaul" <[email protected]>
> Cc: "Laszlo Hornyak" <[email protected]>, "engine-devel"
> <[email protected]>
> 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.
Regards
Sharad Mishra
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
