Hi Chet,
I have read this patch which may be commited by your workmate
https://review.openstack.org/#/c/63254
and I have a question to ask:
Case 1:
An user want to build a 8vcpu instance, there may have seven flavors with 8vcpu
which have different topology extra specs:
1s*4c*2t (s=sockets, c=cores, t=threads)
1s*8c*1t
2s*4c*1t
2s*2c*2t
4s*2c*1t
4s*1c*2t
8s*1c*1t
if the user is building this instance manaually, such as CLI or horizon, he
know the supported topology of image, and can choose the flavor/topology he
really want(eg. 2s*4c*1t),
but if the user is building instance through nova RESTful api from another
service such as heat, which flavor should be chosen and howt to choose?
one more serious problem is that, even the user is a real people, he may don't
know how to choose a flavor with best topology.
We should choose the `better` topology, may not be the best one, for all users
if he want(set the topology in image property), otherwise they use the default
one(vcpu num=socket num).
2014-01-17
Wangpan
发件人：Chet Burgess <c...@metacloud.com>
发送时间：2013-12-22 07:28
主题：Re: [openstack-dev] [Nova] Blueprint: standard specification of guest CPU
topology
收件人："OpenStack Development Mailing List (not for usage
questions)"<openstack-dev@lists.openstack.org>
抄送：
After reading up on the proposed design I have some concerns, primarily around
the use of image properties to represent the topology.
While I see the relationship between images and CPU topology (as referenced in
the wiki Windows licenses and its restrictions on sockets being a prime
example) it seems very confusing to be defining information about the CPU
topology in 2 places. Flavors already define a maximal number of CPUs that can
be allocated and all scheduling decisions related to CPU today use the value of
VCPU specified by the flavor.
I foresee the following operational issues with having these split:
Having CPU topology restrictions in the image may lead to the inability to
resize VMs to take advantage of additional compute power. Its not uncommon in
enterprise deployments for VMs to be resized as the need for the services
running on the VM increases. If the image is defining a portion of the topology
then resizing a VM may result in an incompatible topology or a sub-optimial
topology. This could lead to resizes requiring a rebuild of the VM.
A single image may have a number of valid CPU topologies. Work would have to
be done to allow the user to select which topology they wanted or images would
have to be duplicated multiple times just to specify alternate, valid CPU
topologies.
The flavor should specify the CPU topology as well as the maximum VCPU count.
This should allow resizes to work with minimal change and it avoids the need
for complex selection logic from multiple valid topologies, or duplication of
images. Additionally, the path of least resistance is to simply represent this
as extra_specs on the flavor. Finally extra_specs has the benefit of already
being fully supported by the CLI and Horizon.
Images would still need the ability to specify restrictions on the topology. It
should be fairly easy to enhance the existing core filter of the scheduler to
handle the basic compatibility checks required to validate that a a given image
and flavor are compatible (Note: I suspect this has to occur regardless of the
implementation as having the image specify the topology could still lead to
incompatible combinations). Adding restrictions
--
Chet Burgess
Vice President, Engineering | Metacloud, Inc.
Email: c...@metacloud.com | Tel: 855-638-2256, Ext. 2428
On Nov 19, 2013, at 4:15 , Daniel P. Berrange <berra...@redhat.com> wrote:
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
