<p dir="ltr">>Or, migration scheduling would need to respect the constraint that a<br>
port may be confined to a set of hosts.  How can be assign a port to a<br>
different network?  The VM would wake up and what?  How would it know<br>
to reconfigure its network stack?</p>
<p dir="ltr">Right, that's a big mess. Once a network is picked for a port I think we just need to rely on a scheduler filter that limits the migration to where that network is available. </p>
<div class="gmail_quote">On Jul 23, 2015 8:28 AM, "Carl Baldwin" <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br>
>>It seems to me that the existence of the multiprovider extension is an<br>
>> important point for this discussion.  Multiprovider, as I understand it,<br>
>> allows describing a network composed of multiple L2 segments with implicit<br>
>> east-west routing between them.<br>
><br>
> Not quite. Multiprovider is to describe different L2 segments that are all<br>
> connected together via some kind of translator (e.g. l2 gateway) that<br>
> ensures they are all part of the same broadcast domain. It doesn't fit with<br>
> what we are looking to achieve because all of the segments are supposed to<br>
> be part of the same broadcast domain so there is only one DHCP instance for<br>
> all segments, subnets are shared between all of them, a router only attaches<br>
> to one, etc.<br>
<br>
I share Kevin's understanding of multi-provider networks.  Well-stated, Kevin.<br>
<br>
>>But I was suggesting that there might be some scenarios where routing<br>
> happened without a corresponding router object, and in fact it appears<br>
> that this is already the case: between the segments of a multiprovider<br>
> network.<br>
><br>
> There isn't routing between different subnets for multiprovider networks. A<br>
> multiprovider network is just an l2 broadcast domain realized on multiple<br>
> encapsulation mediums.<br>
<br>
This was my understanding too.<br>
<br>
>>I think Ian's posts have now clarified this.  The current order of<br>
> events is:<br>
>>- Neutron creates an unbound port, associated with a network, and<br>
> allocates an IP address for it.<br>
>>- Nova chooses a host for the new VM.<br>
>>- The port is bound and plugged on that host.<br>
><br>
> This is only the case if someone passes a port UUID into Nova to use. If<br>
> Nova creates the port itself, it will wait until it's scheduled to a compute<br>
> node so the port creation request should already have the host_id field set.<br>
<br>
I like this better than delaying IP address assignment until host<br>
binding occurs.<br>
<br>
> Supporting the case a pre-created port and migration will be the issue. We<br>
> would essentially need to allow ports to be re-assigned to different<br>
> networks to handle these scenarios.<br>
<br>
Or, migration scheduling would need to respect the constraint that a<br>
port may be confined to a set of hosts.  How can be assign a port to a<br>
different network?  The VM would wake up and what?  How would it know<br>
to reconfigure its network stack?<br>
<br>
Carl<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>