Open Stack

Hi Daniel,

Thanks for your help in advance.
I have read your wiki page and it explains this issue very clearly.
But I have a question about the 'technical design', you give us a prototype method as below:
def get_guest_cpu_topology(self, inst_type, image, preferred_topology, mandatory_topology):
my question is that, how/where we can get these two parameters 'preferred_topology, mandatory_topology'?
from the nova config file? or get from the hypervisor?

Thanks again.

2013-11-20



Wangpan



发件人："Daniel P. Berrange" <berrange at redhat.com>
发送时间：2013-11-19 20:15
主题：[openstack-dev] [Nova] Blueprint: standard specification of guest CPU topology
收件人："openstack-dev"<openstack-dev at lists.openstack.org>
抄送：

For attention of maintainers of Nova virt drivers 

A while back there was a bug requesting the ability to set the CPU 
topology (sockets/cores/threads) for guests explicitly 

   https://bugs.launchpad.net/nova/+bug/1199019 

I countered that setting explicit topology doesn't play well with 
booting images with a variety of flavours with differing vCPU counts. 

This led to the following change which used an image property to 
express maximum constraints on CPU topology (max-sockets/max-cores/ 
max-threads) which the libvirt driver will use to figure out the 
actual topology (sockets/cores/threads) 

  https://review.openstack.org/#/c/56510/ 

I believe this is a prime example of something we must co-ordinate 
across virt drivers to maximise happiness of our users. 

There's a blueprint but I find the description rather hard to 
follow 

  https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topology 

So I've created a standalone wiki page which I hope describes the 
idea more clearly 

  https://wiki.openstack.org/wiki/VirtDriverGuestCPUTopology 

Launchpad doesn't let me link the URL to the blueprint since I'm not 
the blurprint creator :-( 

Anyway this mail is to solicit input on the proposed standard way to 
express this which is hypervisor portable and the addition of some 
shared code for doing the calculations which virt driver impls can 
just all into rather than re-inventing 

I'm looking for buy-in to the idea from the maintainers of each 
virt driver that this conceptual approach works for them, before 
we go merging anything with the specific impl for libvirt. 

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-dev mailing list 
OpenStack-dev at lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/ab54c33a/attachment.html>