----- Original Message ----- > From: "Laszlo Hornyak" <[email protected]> > To: "Yaniv Kaul" <[email protected]> > Cc: "engine-devel" <[email protected]> > Sent: Wednesday, December 5, 2012 5:24:59 PM > Subject: Re: [Engine-devel] host cpu feature > > > ----- Original Message ----- > > From: "Yaniv Kaul" <[email protected]> > > To: "Laszlo Hornyak" <[email protected]> > > Cc: "Dan Kenigsberg" <[email protected]>, "engine-devel" > > <[email protected]> > > 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" <[email protected]> > > >> To: "Yaniv Kaul" <[email protected]> > > >> Cc: "Laszlo Hornyak" <[email protected]>, "engine-devel" > > >> <[email protected]> > > >> 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. 2. host-passthrough should be available only for non migratable VMs. > > Y. > > > > > > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
