[Engine-devel] host cpu feature

[Laszlo Hornyak]

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, "engine-devel" <engine-devel at 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 at redhat.com>
> >> To: "Yaniv Kaul" <ykaul at redhat.com>
> >> Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel"
> >> <engine-devel at 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 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.

> Y.
> 
> 
> 
>