Open Stack

Hi,
I think that this information should be used as part of the scheduling
decision, that is hosts that are to be selected should be excluded if they
do not have the necessary resources available. It will be interesting to
know how this is going to fit into the new scheduler that is being
discussed.
Thanks
Gary

On 12/3/13 9:05 AM, "Vui Chiap Lam" <vuichiap at vmware.com> wrote:

>Hi Daniel,
>
>I too found the original bp a little hard to follow, so thanks for
>writing up the wiki! I see that the wiki is now linked to the BP,
>which is great as well.
>
>The ability to express CPU topology constraints for the guests
>has real-world use, and several drivers, including VMware, can definitely
>benefit from it.
>
>If I understand correctly, in addition to being an elaboration of the
>BP text, the wiki also adds the following:
>
>1. Instead of returning the besting matching (num_sockets (S),
>   cores_per_socket (C), threads_per_core (T)) tuple,  all applicable
>   (S,C,T) tuples are returned, sorted by S then C then T.
>2. A mandatory topology can be provided in the topology computation.
>
>I like 2. because there are multiple reasons why all of a hypervisor's
>CPU resources cannot be allocated to a single virtual machine.
>Given that the mandatory (I prefer maximal) topology is probably fixed
>per hypervisor, I wonder this information should also be used in
>scheduling time to eliminate incompatible hosts outright.
>
>As for 1. because of the order of precendence of the fields in the
>(S,C,T) tuple, I am not sure how the preferred_topology comes into
>play. Is it meant to help favor alternative values of S?
>
>Also it might be good to describe a case where returning a list of
>(S,C,T) instead of best-match is necessary. It seems deciding what to
>pick other that the first item in the list requires logic similar to
>that used to arrive at the list in the first place.
>
>Cheers,
>Vui
>
>----- Original Message -----
>| From: "Daniel P. Berrange" <berrange at redhat.com>
>| To: openstack-dev at lists.openstack.org
>| Sent: Monday, December 2, 2013 7:43:58 AM
>| Subject: Re: [openstack-dev] [Nova] Blueprint: standard specification
>of guest CPU topology
>| 
>| On Tue, Nov 19, 2013 at 12:15:51PM +0000, Daniel P. Berrange wrote:
>| > For attention of maintainers of Nova virt drivers
>| 
>| Anyone from Hyper-V or VMWare drivers wish to comment on this
>| proposal....
>| 
>| 
>| > A while back there was a bug requesting the ability to set the CPU
>| > topology (sockets/cores/threads) for guests explicitly
>| > 
>| >    
>https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova
>/%2Bbug/1199019&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoM
>Qu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moC
>UbU%3D%0A&s=70afb246aba2f9c981372e632886ea05fa67ceb6f428499127ac2bdce92a16
>b5
>| > 
>| > 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://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%2
>3/c/56510/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2B
>fDtysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3
>D%0A&s=031f659eb2ed65049eff1e7074ac72f409b5d8df6dbdbf686c18b17a53a671fd
>| > 
>| > 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://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
>t/nova/%2Bspec/support-libvirt-vcpu-topology&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D
>%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kI
>T8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=aecbdaa964bd364860bf8253898b87aaf
>44219fce49f9b7253e5f320db5c3a90
>| > 
>| > So I've created a standalone wiki page which I hope describes the
>| > idea more clearly
>| > 
>| >   
>https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wiki
>/VirtDriverGuestCPUTopology&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZ
>o8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg
>2c15UU252moCUbU%3D%0A&s=898cadf5e157fb7efcac9b90d079ebb83186bd820f54191be6
>fcd6b1f417caf2
>| > 
>| > 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.
>| 
>| 
>| Daniel
>| --
>| |: 
>https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2
>BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
>3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=ed003dd616e595
>34ad1520dffba9255a61f5ade9295be8d5e2dcc66377bc2aa1      -o-
>https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
>errange/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfD
>tysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%
>0A&s=14d20cd29ae81112db407a1362264c6e959614ec7738ee2a36feb60622980b87 :|
>| |: 
>https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=bbf6fdbea326ae0
>3d080ad06c39ee09f83d7dc716015ff1fbf71062a38eee2d6              -o-
>     
>https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/&k=oIvR
>g1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
>Eq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=b0c3ccebce
>48051261531c84e02b1373f71dcc99b5a08b7d5ad10d6fb1b22df8 :|
>| |: 
>https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1%
>2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
>%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=0035ee77abb58
>8ef3b8f7aeb05ee942afcbd521f82899d501c1222afa857ad5a       -o-
>https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
>/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
>kPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=c1
>5f48110b072c10b5f3b6eea6f13ba049b38da5228b73c916fd9666da768b43 :|
>| |: 
>https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/&k=oI
>vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
>xPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=8e3414fb
>dcfb90583a406bfa1e6b0c7757aee9383923f5fb286f3939007b7eb8       -o-
>https://urldefense.proofpoint.com/v1/url?u=http://live.gnome.org/gtk-vnc&k
>=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
>CZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6ELGrXmg2c15UU252moCUbU%3D%0A&s=724a3
>72e9fe22720fe86b7ab45e8a0cb6917e3bd2f02e53f49967a6b8aebbdee :|
>| 
>| _______________________________________________
>| OpenStack-dev mailing list
>| OpenStack-dev at lists.openstack.org
>| 
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6
>ELGrXmg2c15UU252moCUbU%3D%0A&s=231bc63abe86956647740187820b7aacfba4b3b41c8
>4ded1220e3e9872acb71a
>| 
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=tDrRJoA74kIT8OYoO6rN6
>ELGrXmg2c15UU252moCUbU%3D%0A&s=231bc63abe86956647740187820b7aacfba4b3b41c8
>4ded1220e3e9872acb71a