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