Open Stack

On Fri, Jan 11, 2013 at 02:25:52AM +0000, Jiang, Yunhong wrote:
> > 
> > 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.

I didn't imply any difference in those terms. 

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

This isn't a new or difficult problem - you'll have to do that one way
or another no matter how you go about modelling this, because different
hypervisors have different ways of confinguring CPUs.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|