Open Stack

> 
> Again we intentionally don't expose this information because applying
> logic based on CPU feature flags is fundamentally non-portable
> 

> We provide an API which allows you to pass in a CPU description (where
> a CPU description == a CPU model name + a list of features), and returns
> status on whether the host can support that CPU description. This keeps
> mgmt applications of the business of doing architecture specific CPU
> comparisons.


Daniel, can you please elaborate the difference of cpu feature flags and CPU feature?
>From you description, seems CPU feature flags is x86 specifc, while CPU feature is portable. That's a bit confusing to me.

......

> IMHO the interaction between schedular and hypervisor hosts wrt to
> CPU model is flawed, not least because of the problems described
> above, but also because the CPU information provoided is not
> standardized across Nova hypervisor drivers at all.
> 
> I think that Nova needs to have a formal concept of CPU types, with
> arbitrary names it decides upon, eg it might allow a list of CPU
> types:
> 
>   "Westmere"
>   "Nehalem"
>   "Any Host"
>   "Any Intel"
>   "Any AMD"
>   "Any AES"
> 
> Each hypervisor (libvirt, xen, hyper-v, esx, etc) would decide how
> these CPU types map to their particular way of configuring CPUs
> (libvirt would map them to CPU model + feature list, Xen would map
> them to a CPUID string, VMWare would do whatever it does).

Even if we take this method, we still need make sure same CPU type has same CPU features across different hypervisor. Let the hypervisor make the decision seems problematic to me.

--jyh