On Fri, Mar 13, 2015 at 08:42:25AM -0400, Steve Gordon wrote: > ----- Original Message ----- > > From: "park" <jianlong...@gmail.com> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
