Open Stack

On Jan 9, 2013, at 1:59 PM, "Dugger, Donald D" <donald.d.dugger at intel.com> 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.
> 
> 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.

I think using libvirt (or any hypervisor that provides the functionality) is probably the best way to do this, since the hypervisor is going to have the best idea of what features it actually supports. For example the hypervisor might have extra security that prevents it from using some cpu features that are available on the host. This is also important for xenapi where the nova-compute host != the virtualization host.

Therefore it sounds like your patch to list all cpu features sounds like the right way to go to me.

Vish