<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> <!--@import url(scrollbar.css); --></STYLE>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<STYLE> body{FONT-SIZE:12pt; FONT-FAMILY:宋体,serif;} </STYLE>
<META name=GENERATOR content="MSHTML 8.00.7600.16385"><BASE
target=_blank></HEAD>
<BODY
style="LINE-HEIGHT: 1.3; BORDER-RIGHT-WIDTH: 0px; MARGIN: 12px; BORDER-TOP-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; BORDER-LEFT-WIDTH: 0px"
marginheight="0" marginwidth="0">
<DIV><FONT color=#000000 size=3 face=宋体>Hi Chet,</FONT></DIV>
<DIV><FONT color=#000000 size=3 face=宋体>I have read this patch which may be
commited by your workmate <A
href="https://review.openstack.org/#/c/63254">https://review.openstack.org/#/c/63254</A></FONT></DIV>
<DIV>and I have a question to ask:</DIV>
<DIV>Case 1:</DIV>
<DIV>An user want to build a 8vcpu instance, there may have seven flavors
with 8vcpu which have different topology extra specs:</DIV>
<DIV>1s*4c*2t (s=sockets, c=cores, t=threads)</DIV>
<DIV>1s*8c*1t</DIV>
<DIV>2s*4c*1t</DIV>
<DIV>2s*2c*2t</DIV>
<DIV>4s*2c*1t</DIV>
<DIV>4s*1c*2t</DIV>
<DIV>8s*1c*1t</DIV>
<DIV>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),</DIV>
<DIV>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?</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV align=left><FONT color=#c0c0c0 size=2 face=Verdana>2014-01-17</FONT></DIV>
<DIV align=left><FONT size=2 face=Verdana>
<HR style="WIDTH: 122px; HEIGHT: 2px" id=SignNameHR align=left SIZE=2>
</FONT></DIV>
<DIV align=left><FONT color=#c0c0c0 size=2 face=Verdana><SPAN
id=_FlashSignName>Wangpan</SPAN></FONT></DIV>
<DIV><FONT size=2 face=Verdana>
<HR>
</FONT></DIV>
<DIV><FONT size=2 face=Verdana><STRONG>发件人：</STRONG>Chet Burgess
<cfb@metacloud.com></FONT></DIV>
<DIV><FONT size=2
face=Verdana><STRONG>发送时间：</STRONG>2013-12-22 07:28</FONT></DIV>
<DIV><FONT size=2 face=Verdana><STRONG>主题：</STRONG>Re: [openstack-dev] [Nova]
Blueprint: standard specification of guest CPU topology</FONT></DIV>
<DIV><FONT size=2 face=Verdana><STRONG>收件人：</STRONG>"OpenStack Development
Mailing List (not for usage
questions)"<openstack-dev@lists.openstack.org></FONT></DIV>
<DIV><FONT size=2 face=Verdana><STRONG>抄送：</STRONG></FONT></DIV>
<DIV><FONT size=2 face=Verdana></FONT> </DIV>
<DIV><FONT size=2 face=Verdana>After reading up on the proposed design I have
some concerns, primarily around the use of image properties to represent the
topology.
<DIV><BR></DIV>
<DIV>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. </DIV>
<DIV><BR></DIV>
<DIV>I foresee the following operational issues with having these split:</DIV>
<DIV>
<OL>
<LI>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.
<LI>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.</LI></OL></DIV>
<DIV>
<DIV><BR></DIV>
<DIV>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.</DIV>
<DIV><BR></DIV>
<DIV>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 </DIV>
<DIV><BR></DIV>
<DIV>
<DIV apple-content-edited="true">
<DIV
style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; WORD-WRAP: break-word; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px; -webkit-text-stroke-width: 0px; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">--<BR>Chet
Burgess<BR>Vice President, Engineering | Metacloud, Inc.<BR>Email: <A
href="mailto:cfb@metacloud.com">cfb@metacloud.com</A> | Tel: 855-638-2256, Ext.
2428</DIV></DIV><BR>
<DIV>
<DIV>On Nov 19, 2013, at 4:15 , Daniel P. Berrange <<A
href="mailto:berrange@redhat.com">berrange@redhat.com</A>> wrote:</DIV><BR
class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">For attention of maintainers of Nova virt
drivers<BR><BR>A while back there was a bug requesting the ability to set the
CPU<BR>topology (sockets/cores/threads) for guests
explicitly<BR><BR> <A
href="https://bugs.launchpad.net/nova/+bug/1199019">https://bugs.launchpad.net/nova/+bug/1199019</A><BR><BR>I
countered that setting explicit topology doesn't play well with<BR>booting
images with a variety of flavours with differing vCPU counts.<BR><BR>This led
to the following change which used an image property to<BR>express maximum
constraints on CPU topology (max-sockets/max-cores/<BR>max-threads) which the
libvirt driver will use to figure out the<BR>actual topology
(sockets/cores/threads)<BR><BR> <A
href="https://review.openstack.org/#/c/56510/">https://review.openstack.org/#/c/56510/</A><BR><BR>I
believe this is a prime example of something we must co-ordinate<BR>across
virt drivers to maximise happiness of our users.<BR><BR>There's a blueprint
but I find the description rather hard to<BR>follow<BR><BR> <A
href="https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topology">https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topology</A><BR><BR>So
I've created a standalone wiki page which I hope describes the<BR>idea more
clearly<BR><BR> <A
href="https://wiki.openstack.org/wiki/VirtDriverGuestCPUTopology">https://wiki.openstack.org/wiki/VirtDriverGuestCPUTopology</A><BR><BR>Launchpad
doesn't let me link the URL to the blueprint since I'm not<BR>the blurprint
creator :-(<BR><BR>Anyway this mail is to solicit input on the proposed
standard way to<BR>express this which is hypervisor portable and the addition
of some<BR>shared code for doing the calculations which virt driver impls
can<BR>just all into rather than re-inventing<BR><BR>I'm looking for buy-in to
the idea from the maintainers of each<BR>virt driver that this conceptual
approach works for them, before<BR>we go merging anything with the specific
impl for libvirt.<BR><BR>Regards,<BR>Daniel<BR>-- <BR>|: <A
href="http://berrange.com">http://berrange.com</A>
-o- <A
href="http://www.flickr.com/photos/dberrange/">http://www.flickr.com/photos/dberrange/</A>
:|<BR>|: <A href="http://libvirt.org">http://libvirt.org</A>
-o-
<A
href="http://virt-manager.org">http://virt-manager.org</A> :|<BR>|: <A
href="http://autobuild.org">http://autobuild.org</A>
-o-
<A
href="http://search.cpan.org/~danberr/">http://search.cpan.org/~danberr/</A>
:|<BR>|: <A href="http://entangle-photo.org">http://entangle-photo.org</A>
-o- <A
href="http://live.gnome.org/gtk-vnc">http://live.gnome.org/gtk-vnc</A>
:|<BR><BR>_______________________________________________<BR>OpenStack-dev
mailing list<BR><A
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</A><BR>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<BR></BLOCKQUOTE></DIV><BR></DIV></DIV></FONT></DIV></BODY></HTML>