----- Original Message ----- > From: "Laszlo Hornyak" <lhorn...@redhat.com> > To: "Doron Fediuck" <dfedi...@redhat.com> > Cc: "engine-devel" <engine-devel@ovirt.org>, "Yaniv Kaul" <yk...@redhat.com> > Sent: Wednesday, December 5, 2012 6:41:24 PM > Subject: Re: [Engine-devel] host cpu feature > > > > ----- Original Message ----- > > From: "Doron Fediuck" <dfedi...@redhat.com> > > To: "Laszlo Hornyak" <lhorn...@redhat.com> > > Cc: "engine-devel" <engine-devel@ovirt.org>, "Yaniv Kaul" > > <yk...@redhat.com> > > Sent: Wednesday, December 5, 2012 5:33:35 PM > > Subject: Re: [Engine-devel] host cpu feature > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" <lhorn...@redhat.com> > > > To: "Yaniv Kaul" <yk...@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 > > > > > > > > > ----- Original Message ----- > > > > From: "Yaniv Kaul" <yk...@redhat.com> > > > > To: "Laszlo Hornyak" <lhorn...@redhat.com> > > > > Cc: "Dan Kenigsberg" <dan...@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" <dan...@redhat.com> > > > > >> To: "Yaniv Kaul" <yk...@redhat.com> > > > > >> Cc: "Laszlo Hornyak" <lhorn...@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 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. > > > > > > > > > > > > > > > > > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel