Open Stack

On Wed, Jan 09, 2013 at 09:59:01PM +0000, Dugger, Donald D wrote:
> Currently, each compute node periodically sends info to the scheduler
> including a list of the CPU features available on that node.  Unfortunately
> the CPU features listed does not appear to be complete, making it extremely
> difficult to identify exactly what features are available on a host.
> 
> The problem is that compute nodes call the libvirt API `virConnectGetCapabilities'
> to get host features and then just send the output from this API to the scheduler.
> The issue is that libvirt reports the model name and only explicitly reports CPU
> features that are not part of that model.  For example, on my Westmere host the
> Advanced Encryption Standard (`aes') capability is not reported since that
> capability is available on all Westmere's.
> 
> This is a distinct problem as it makes it well nigh impossible for a user to know
> how to check for specific capabilities.  Asking the user to know that Westmere,
> SandyBridge and Haswell machines have `aes' while Conroe, Penryn and Nehalem
> machines don't is a little ridiculous, ignoring the fact that these are all
> internal Intel code names that end users shouldn't even know about in the first
> place.

Nowhere do we ask the user to know about this information. It is information that
is purely internal to OpenStack infrastructure, which the user does not need to
interact with.

The libvirt CPU API was explicitly designed so that you don't just provide
a list of features and have the virtualization app do feature flag matching
because this only works on x86. If you want to do comparisons & supportability
checks then there are libvirt APIs to enable this. You provide a description
of the desired model / features and ask libvirt if it is compatible with the
virtualization host & it will tell you. Alternatively when booting the guest
you can say only boot this guest if the host cna support model/feature xyz.
This approach works on x86, PPC, s390 and ARM, hence why it was chosen.

> I have a patch that fixes libvirt (the patch still reports the model name but
> explicitly lists ALL cpu features) but I'm not sure that is the proper way to
> fix the problem.  Personally, I don't like the fact that the host calls a
> virtualization API in order to discover info about the host itself, that
> just seems wrong.  I'd prefer to see OpenStack discover this info directly,
> not using libvirt APIs, avoiding this kind of problem now and in the future.

On the contrary, using the hypervisor APIs is the right way todo this. You can
not assume that the host CPU features are all available to the virtualization
technology. You must ask the virtualization technology to report what features
from the host it can use. Furthermore, as I describe above the approach libvirt
takes is based on the requirement to be portable across architectures. You are
proposing that we switch to an x86-specific approach which is not desirable
given OpenStack targets non-x86 platforms.

> Anyone have any thoughts on the proper way to discover CPU capabilities.

Can you explain the actual problem you are trying to solve, rather than
your desired solution.

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