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" <[email protected]>
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
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?
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
