Hi clint, matt.<br><br>To be noticed that post-copy and auto-convergence are mutually exclusive.<br><br>The drawbacks that we experienced with here is that live-migration using either way post-copy or auto-convergence will likely fail for application not being able to handle throttling. Although, post-copy is guaranteed to work for most of your migration.<br><br>On the design part of your solution. For a while we had the same design with each rack being segmented but we gave up with this choice as it was a PITA especially for live-migration.<br><br>We’re currently migrating our network design to a much simplified all L3 network layout with our underlying network a bgp driven network and all overlay network being managed by Openstack.<br><br>Let me know if you need more details or information.<br><br>Kind regards,<br>G.<br><br><br><br><div class="gmail_quote"><div dir="ltr">Le mar. 7 août 2018 à 01:44, Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/6/2018 8:12 AM, Clint Byrum wrote:<br>
> First a few facts about our installation:<br>
> <br>
> * We're using kolla-ansible and basically leaving most nova settings at <br>
> the default, meaning libvirt+kvm<br>
> * We will be using block migration, as we have no shared storage of any <br>
> kind.<br>
> * We use routed networks to set up L2 segments per-rack. Each rack is <br>
> basically an island unto itself. The VMs on one rack cannot be migrated <br>
> to another rack  because of this.<br>
> * Our main resource limitation is disk, followed closely by RAM. As <br>
> such, our main motivation for wanting to do live migration is to be able <br>
> to move VMs off of machines where over-subscribed disk users start to <br>
> threaten the free space of the others.<br>
<br>
What release are you on?<br>
<br>
> <br>
> * Do people have feedback on live_migrate_permit_auto_convergence? It <br>
> seems like a reasonable trade-off, but since it is defaulted to false, I <br>
> wonder if there are some hidden gotchas there.<br>
<br>
You might want to read through [1] and [2]. Those were written by the <br>
OSIC dev team when that still existed. But there are some (somewhat <br>
mysterious) mentions to caveats with post-copy you should be aware of. <br>
At this point, John Garbutt is probably the best person to talk to about <br>
those since all of the other OSIC devs that worked on this spec are long <br>
gone.<br>
<br>
 ><br>
 > * General pointers to excellent guides, white papers, etc, that might <br>
help us avoid doing all of our learning via trial/error.<br>
<br>
Check out [3]. I've specifically been meaning to watch the one from <br>
Boston that John was in.<br>
<br>
[1] <br>
<a href="https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-force-after-timeout.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-force-after-timeout.html</a><br>
[2] <br>
<a href="https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-per-instance-timeout.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-per-instance-timeout.html</a><br>
[3] <a href="https://www.openstack.org/videos/search?search=live%20migration" rel="noreferrer" target="_blank">https://www.openstack.org/videos/search?search=live%20migration</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div>