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 :|