settingsLogin | Registersettings

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

0 votes

----- Original Message -----

From: "park" jianlonghei@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"=" ***"
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 cpumode=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, cpumode/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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Mar 13, 2015 in openstack-dev by Steve_Gordon (9,680 points)   2 5 7

4 Responses

0 votes

On 2015年03月13日 20:42, Steve Gordon wrote:
----- Original Message -----

From: "park" jianlonghei@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"=" ***"
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 cpumode=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, cpumode/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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 13, 2015 by park (300 points)   1
0 votes

On Fri, Mar 13, 2015 at 08:42:25AM -0400, Steve Gordon wrote:
----- Original Message -----

From: "park" jianlonghei@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"=" ***"
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 cpumode=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 'cpumode=host-model' or 'cpumode=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:cpuinfo: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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 13, 2015 by Daniel_P._Berrange (27,920 points)   2 4 10
0 votes

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@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"=" ***"
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 cpumode=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 'cpumode=host-model' or 'cpumode=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:cpuinfo: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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 13, 2015 by Chris_Friesen (20,420 points)   4 17 26
0 votes

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" jianlonghei@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"=" ***"
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 cpumode=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 'cpumode=host-model' or 'cpumode=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:cpuinfo: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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 13, 2015 by Daniel_P._Berrange (27,920 points)   2 4 10
...