Re: [Engine-devel] host cpu feature

----- Original Message ----- > From: "Dan Kenigsberg" <danken(a)redhat.com&gt; > To: "Yaniv Kaul" <ykaul(a)redhat.com&gt; > Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; > 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