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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to