Hi Keshava, To the best of my knowledge Nova does not have an explicit way to determine VM placements based on network attributes. That said, it does have a general mechanism called host-aggregates [1] that can be leveraged to address what you are looking for. How certain hosts are grouped together to match certain network affinity rules is in the hands of the cloud operator and I believe this requires quite a bit of out-of-band management. I recall at one point that there was an effort going on to improve the usability of such a use case (using the port binding extension [2]), but my knowledge is not very current, so I'd need to fall back on some other folks listening on the ML to chime in on the latter topic. Hope this help! Armando [1] - http://docs.openstack.org/trunk/openstack-ops/content/scaling.html#segregate_cloud [2] - http://docs.openstack.org/api/openstack-network/2.0/content/binding_ext_ports.html On 27 May 2014 09:53, A, Keshava <keshava.a at hp.com> wrote: > Hi, > > I have one of the basic question about the Nova Scheduler in the following > below scenario. > > Whenever a new VM to be hosted is there any consideration of network > attributes ? > > Example let us say all the VMs with 10.1.x is under TOR-1, and 20.1.xy are > under TOR-2. > > A new CN nodes is inserted under TOR-2 and at same time a new tenant VM > needs to be hosted for 10.1.xa network. > > > > Then is it possible to mandate the new VM(10.1.xa) to hosted under TOR-1 > instead of it got scheduled under TOR-2 ( where there CN-23 is completely > free from resource perspective ) ? > > This is required to achieve prefix/route aggregation and to avoid network > broadcast (incase if they are scattered across different TOR/Switch) ? > > > > > > > > > > Thanks & regards, > > Keshava.A > > > > _______________________________________________ > 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/20140529/bb4c29d7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 30014 bytes Desc: not available URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140529/bb4c29d7/attachment.png>