[Engine-devel] host cpu feature

[Doron Fediuck]

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Yaniv Kaul" <ykaul at redhat.com>
> Sent: Wednesday, December 5, 2012 6:41:24 PM
> Subject: Re: [Engine-devel] host cpu feature
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Yaniv Kaul"
> > <ykaul at redhat.com>
> > Sent: Wednesday, December 5, 2012 5:33:35 PM
> > Subject: Re: [Engine-devel] host cpu feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "Yaniv Kaul" <ykaul at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, December 5, 2012 5:24:59 PM
> > > Subject: Re: [Engine-devel] host cpu feature
> > > 
> > > 
> > > ----- 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.
> > > 
> > 
> > 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.

> > 
> > 
> > > > Y.
> > > > 
> > > > 
> > > > 
> > > > 
> > 
>