[openstack-dev] Host CPU feature exposure

Dugger, Donald D donald.d.dugger at intel.com
Wed Jan 9 21:59:01 UTC 2013


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.

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

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786




More information about the OpenStack-dev mailing list