[Engine-devel] host cpu feature

[Dan Kenigsberg]

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.

> >>>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."