Re: [openstack-dev] [nova] The libvirt.cpu_mode and libvirt.cpu_model
> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: Thursday, January 29, 2015 2:34 AM > To: Jiang, Yunhong > Cc: openstack-dev@lists.openstack.org > Subject: Re: [nova] The libvirt.cpu_mode and libvirt.cpu_model > > On Wed, Jan 28, 2015 at 10:10:29PM +, Jiang, Yunhong wrote: > > Hi, Daniel > > I recently tried the libvirt.cpu_mode and libvirt.cpu_model > > when I was working on cpu_info related code and found bug > > https://bugs.launchpad.net/nova/+bug/1412994 . The reason is because > > with these two flags, all guests launched on the host will use them, > > while when host report back the compute capability, they report the > > real-hardware compute capability, instead of the compute capabilities > > masked by these two configs. > > > > I think the key thing is, these two flags are per-instance properties > > instead of per-host properties. > > No, these are intended to be per host properties. The idea is that all > hosts should be configured with a consistent CPU model so you can live > migrate between all hosts without hitting compatibility probems. There > is however currently a bug in the live migration CPU compat checking > but I have a fix for that in progress. Although configuring all hosts with consistent CPU model means nova live migration issue, does it also means the cloud can only present features based on oldest machine in the cloud, and latest CPU features like SSE4.1 etc can't be utilized? Also, if we want to expose host feature to guest (please check https://bugs.launchpad.net/nova/+bug/1412930 for a related issue), we have to use per-instance cpu_model configuration, which will anyway break the all-host-live-migration. For your live migration fix, is it https://review.openstack.org/#/c/53746/ ? On your patch, the check_can_live_migrate_destination() will use the guest CPU info to compare with the target host CPU info, instead of compare the source/target host cpu_model. Thanks --jyh > > > How about remove these two config items? And I don't think we > > should present cpu_mode/model option to end user, instead, we should > > only expose the feature request like disable/force some cpu_features, > > and the libvirt driver select the cpu_mode/model based on user's > > feature requirement. > > I don't see any reason to remove these config items > > 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] The libvirt.cpu_mode and libvirt.cpu_model
On Wed, Jan 28, 2015 at 10:10:29PM +, Jiang, Yunhong wrote: > Hi, Daniel > I recently tried the libvirt.cpu_mode and libvirt.cpu_model > when I was working on cpu_info related code and found bug > https://bugs.launchpad.net/nova/+bug/1412994 . The reason is because > with these two flags, all guests launched on the host will use them, > while when host report back the compute capability, they report the > real-hardware compute capability, instead of the compute capabilities > masked by these two configs. > > I think the key thing is, these two flags are per-instance properties > instead of per-host properties. No, these are intended to be per host properties. The idea is that all hosts should be configured with a consistent CPU model so you can live migrate between all hosts without hitting compatibility probems. There is however currently a bug in the live migration CPU compat checking but I have a fix for that in progress. > How about remove these two config items? And I don't think we > should present cpu_mode/model option to end user, instead, we should > only expose the feature request like disable/force some cpu_features, > and the libvirt driver select the cpu_mode/model based on user's > feature requirement. I don't see any reason to remove these config items 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
[openstack-dev] [nova] The libvirt.cpu_mode and libvirt.cpu_model
Hi, Daniel I recently tried the libvirt.cpu_mode and libvirt.cpu_model when I was working on cpu_info related code and found bug https://bugs.launchpad.net/nova/+bug/1412994 . The reason is because with these two flags, all guests launched on the host will use them, while when host report back the compute capability, they report the real-hardware compute capability, instead of the compute capabilities masked by these two configs. I think the key thing is, these two flags are per-instance properties instead of per-host properties. If we do want to keep it as per-host property, libvirt driver should return the capabilities that has been altered by these two items, but the problem is, I checked libvirt doc and seems we can't get the cpu_info for the custom cpu_mode. How about remove these two config items? And I don't think we should present cpu_mode/model option to end user, instead, we should only expose the feature request like disable/force some cpu_features, and the libvirt driver select the cpu_mode/model based on user's feature requirement. Your opinion? Thanks --jyh __ 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
