----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Laszlo Hornyak" <lhornyak@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 5, 2012 6:48:33 PM Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 06:46 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Yaniv Kaul" <ykaul@redhat.com> Sent: Wednesday, December 5, 2012 6:41:24 PM Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Laszlo Hornyak" <lhornyak@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Yaniv Kaul" <ykaul@redhat.com> Sent: Wednesday, December 5, 2012 5:33:35 PM Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 5, 2012 5:24:59 PM Subject: Re: [Engine-devel] host cpu feature
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Laszlo Hornyak" <lhornyak@redhat.com> Cc: "Dan Kenigsberg" <danken@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 5, 2012 4:10:13 PM Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 04:59 PM, Laszlo Hornyak wrote: > ----- Original Message ----- >> From: "Dan Kenigsberg" <danken@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 3:22:18 PM >> Subject: Re: [Engine-devel] host cpu feature >> >> On Wed, Dec 05, 2012 at 04:05:00PM +0200, Yaniv Kaul wrote: >>> On 12/05/2012 03:55 PM, Laszlo Hornyak wrote: >>>>>>> The nice thing about hostModel (unlike hostPassthrough) >>>>>>> is >>>>>>> that >>>>>>> once >>>>>>> we >>>>>>> created the VM we can migrate it to stronger hosts, and >>>>>>> back >>>>>>> to >>>>>>> the >>>>>>> original host. I suppose that it complicates the >>>>>>> scheduler. >>>>>> Yes with host-model you get the features that libvirt >>>>>> handles. >>>>>> In >>>>>> such cases the engine could decide, if you want this >>>>>> functionality. Well the scheduler architecture is just >>>>>> being >>>>>> reinvented. >>>>>> >>>>>> For the host-passthrough, I think the >>>>>> AllowMigrateCPUHost >>>>>> configuration option would be a simple decision for the >>>>>> administrator: set it to true if all hosts are uniform. >> If it is THAT simple, Engine could take this decision >> without >> human >> intervension. > Is there a way engine can figure out if the cpu-models in all > the > hosts are the same? > I mean even if some host flags are not handled by libvirt and > therefore vdsm and engine... > So I would really need that permission from the user. > >>>>>> If it is >>>>>> not set to true, then we will not allow migration of >>>>>> such >>>>>> VMs. >>>>> That's not what I understood from libvirt's >>>>> documentation. >>>>> I >>>> You may be right, could you send an URL to that point of >>>> the >>>> documentation or copy-paste? >>> The link I followed from your feature page: >>> http://libvirt.org/formatdomain.html#elementsCPU : >>> >>> host-model >>> The host-model mode is essentially a shortcut to copying >>> host >>> CPU >>> definition from capabilities XML into domain XML. Since the >>> CPU >>> definition is copied just before starting a domain, exactly >>> the >>> same >>> XML can be used on different hosts while still providing >>> the >>> best >>> guest CPU each host supports. Neither match attribute nor >>> any >>> feature elements can be used in this mode. Specifying CPU >>> model >>> is >>> not supported either, but model's fallback attribute may >>> still >>> be >>> used. Libvirt does not model every aspect of each CPU so >>> the >>> guest >>> CPU will not match the host CPU exactly. On the other hand, >>> the >>> ABI >>> provided to the guest is reproducible. During migration, >>> complete >>> CPU model definition is transferred to the destination host >>> so >>> the >>> migrated guest will see exactly the same CPU model even if >>> the >>> destination host contains more capable CPUs for the running >>> instance >>> of the guest; but shutting down and restarting the guest >>> may >>> present >>> different hardware to the guest according to the >>> capabilities >>> of >>> the >>> new host. >>> host-passthrough >>> With this mode, the CPU visible to the guest should be >>> exactly >>> the >>> same as the host CPU even in the aspects that libvirt does >>> not >>> understand. Though the downside of this mode is that the >>> guest >>> environment cannot be reproduced on different hardware. >>> Thus, >>> if >>> you >>> hit any bugs, you are on your own. >> That's exactly where AllowMigrateCPUHost fits well: when a >> user >> ticks >> this for a cluster he says "yeah, I like to be on my own." >> > cpu mode="host-passthrough" migration: I talked to the > libvirt > guys > and they said it is OK if the hardware and the software are > the > same, and it will work, but they would not recommend. > > So if they do not recommend it, I would drop this from the > feature > spec. Anyone against it? > > Laszlo I'm a bit against it. I don't see why it's that complicated: Allow migration -> use 'host-model' Do not allow -> use 'host-passthrough'. So the actual cpu capabilities would depend not only on the 'host cpu' checkbox, but also on the 'pinned to host' checkbox. I
----- Original Message ----- think this logical trick would be both funny and confusing from the user's perspective.
The reason of why we need host-passthrough is that otherwise I suspect we depend on libvirt for newer features to be somehow exposed to the guest (not sure about it). Yes, with other words: this is a tuning feature.
Let's keep it simple. 1. Please remove AllowMigrateCPUHost. No reason for us to do what libvirt is asking to void. With pleasure :)
2. host-passthrough should be available only for non migratable VMs. Right.
And no host-model support for now, right?
Right. In can later be added if we have a good reasoning for it.
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.