Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration
On Fri, Mar 13, 2015 at 11:18:15AM -0600, Chris Friesen wrote: > 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" > >>>To: "OpenStack Development Mailing List (not for usage questions)" > >>> > >>> > >>>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"=" ***" > >>>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? If the admin has not enabled host-model/passthrough CPU mode, then they should simply not set the capabilities:cpu_info:features property on the flavours they have setup. 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
Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration
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" To: "OpenStack Development Mailing List (not for usage questions)" 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"=" ***" 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration
On Fri, Mar 13, 2015 at 08:42:25AM -0400, Steve Gordon wrote: > - Original Message - > > From: "park" > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > > > 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"=" ***" > > 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
Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration
On 2015年03月13日 20:42, Steve Gordon wrote: - Original Message - From: "park" To: "OpenStack Development Mailing List (not for usage questions)" 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"=" ***" 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. +1 and I think the CPU configuration should take effect, otherwise, users should be prompted some messages.. -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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration
- Original Message - > From: "park" > To: "OpenStack Development Mailing List (not for usage questions)" > > > 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"=" ***" > 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-requ...@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 __ 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
[openstack-dev] [nova] A question about libvirt cpu mode=none configuration
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"=" ***" 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... 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
