> -----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 +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.

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

Reply via email to