[openstack-dev] [nova] A question about libvirt cpu mode=none configuration

Chris Friesen chris.friesen at windriver.com
Fri Mar 13 17:18:15 UTC 2015

On 03/13/2015 07:50 AM, Daniel P. Berrange wrote:
> On Fri, Mar 13, 2015 at 08:42:25AM -0400, Steve Gordon wrote:
>> ----- Original Message -----
>>> From: "park" <jianlonghei at gmail.com>
>>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
>>> hello Nova
>>> By default, nova libvirt driver configuration for guest cpu as "cpu_mode
>>> = none",
>>> you could add cpu features by changing flavor section as below, there
>>> will NOT
>>> be any issues for this cmd.
>>> $nova flavor-key m1.small set "capabilities:cpu_info:features"="<in> ***"
>>> but, nova will ignore the cpu features after the guest boot up
>>> successfully, which
>>> means the feature does NOT take effect(not be written into the xml for
>>> the guest).
>>> And there is no message telling the users that the features does NOT
>>> take effect...
>>> this may make the users confused...
>> This issue is more general than the cpu_mode=none case, in that the
>> capabilities filter is filtering *hosts* based on their CPU features.
>> As you have discovered, whether they are actually exposing those
>> features to guests in their current configuration is not taken into
>> account (that is, cpu_mode/cpu_model settings aren't considered at
>> all). Ideally they would be, but I'm not sure this is trivial.
> If you set  'cpu_mode=host-model' or 'cpu_mode=host-passthrough'
> then it will take effect, as the guest will see the full CPU model
> of the host that is picked. IMHO the capabilities:cpu_info:features
> filter only makes sense when using those two cpu modes. If you
> left the default cpu_mode=None or set cpu_mode=custom, then this
> capabilities feature is meaningless from a conceptual POV. So the
> fact that it has no effect on the guest CPU is not a bug it is
> by design.

If the cpu features aren't going to be passed through into the guest, does it 
make sense for the scheduler to filter based on them?


More information about the OpenStack-dev mailing list