[openstack-dev] [nova][libvirt] The None and 'none' for CONF.libvirt.cpu_mode

Jiang, Yunhong yunhong.jiang at intel.com
Wed Mar 4 17:24:53 UTC 2015

Daniel, thanks for your clarification.

Another related question is, what will be the guest's real cpu model is the cpu_model is None? This is about a reported regression at https://bugs.launchpad.net/nova/+bug/1082414 . When the instance.vcpu_model.mode is None, we should compare the source/target cpu model, as the suggestion from Tony, am I right?


> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: Wednesday, March 4, 2015 6:56 AM
> To: Jiang, Yunhong
> Cc: openstack-dev at lists.openstack.org; Xu, Hejie
> Subject: Re: [nova][libvirt] The None and 'none' for CONF.libvirt.cpu_mode
> On Wed, Mar 04, 2015 at 02:52:06PM +0000, Jiang, Yunhong wrote:
> > Hi, Daniel
> > 	I'm a bit confused of the None/'none' for CONF.libvirt.cpu_mode.
> Per my understanding, None means there is no configuration provided and
> libvirt will select the default value based on the virt_type, none means no
> cpu_mode information should be provided. For the guest, am I right?
> >
> >               In _get_guest_cpu_model_config() on virt/libvirt/driver.py,
> > if mode is 'none', kvm/qemu virt_type will return a
> > vconfig.LibvirtConfigGuestCPU() while other virt type will return None.
> > What's the difference of this return difference?
> The LibvirtConfigGuestCPU  object is used for more than just configuring
> the CPU model. It is also used for expressing CPU topology (sockets, cores,
> threads) and NUMA topology. So even if cpu model is None, we still need
> that object in the kvm case.
> 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 :|

More information about the OpenStack-dev mailing list