On Wed, Jan 28, 2015 at 10:10:29PM +0000, 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
