[openstack-dev] [nova] A question about libvirt cpu mode=none configuration
Steve Gordon
sgordon at redhat.com
Fri Mar 13 12:42:25 UTC 2015
----- 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.
-Steve
> if we add the feature into the xml file for the guest, this will trigger
> internal error
> "libvirtError: XML error: Non-empty feature list specified without CPU
> model"
>
>
> so what should we do? Leave it as itself(ignore the users input, and
> boot the guest
> successfully), or prompt the users with the errors?
>
> Thanks
> Park
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform
More information about the OpenStack-dev
mailing list