Open Stack

On 08/10/2015 10:11 AM, Dugger, Donald D wrote:
> In re: Different architectures.
>
> I'm not saying we should create architecture specific definitions in our
> APIs.  I like the idea of capabilities being exposed as arbitrary strings
> like "AES" or "AltiVec".  An Intel user would be providing an IA architecture
> image and should know that it makes no sense to request "AltiVec"
> capabilities (and that request would correctly fail as either the image
> wouldn't run on the selected host or no host would be selected).
>
> I'm looking for Nova to provide a common way of exposing and requesting host
> capabilities and you just use appropriate architecture specific strings when
> using these common interfaces.

There are some complications.

For non-x86 architectures they don't have the equivalent of "CPU features" 
exposed.  It's basically all encoded in the CPU model.

For x86, you can't just pick features, you actually need to specify the guest 
CPU model in order to ensure that live-migration is possible between hosts with 
potentially different host CPU models.  Also, the guest CPU model is not 
sufficient by itself, because different cloud vendors mask out different CPU 
features from the guest.  (Still not totally sure why, but apparently they do.)

So specifically for CPU model/features I think we'd want to allow the 
specification of a "CPU flavor", which would expose a vCPU model and (if 
appropriate) a set of features that could be queried.  These would be created by 
the admin, likely to match the underlying hardware available in the cloud. 
(Since it doesn't buy you anything to expose CPU models that don't match up with 
a host CPU model.)

I'm not quite sure how to deal with clouds that have multiple hypervisors, since 
the different hypervisors have subtly different virtual CPU models/features.

Chris