<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.gmail-q4iawc
{mso-style-name:gmail-q4iawc;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Ignazio,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Is it the actual live-migration that takes long (e.g. the libvirt migration you can watch with “virsh domjobinfo <instance>”) or the whole live-migration process as observed by nova.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">We have seen it a few times that the thing that actually takes long is plugging the neutron port on the target hypervisor (although I think this only applies to ml2-ovs). For us this
seems to happen because the neutron-openvswitch-agent can take some time to assemble the firewall rules for the security group of the port (especially if you use large remote security groups).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">This would also explain why migrating back is fast, because the neutron-openvswitch-agent on the source will have the information cached.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Alternatively you could have multiple live-migrations queued for the same source hypervisor, but nova only handles them one-by-one (unless you set max_concurrent_live_migrations).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">--<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Felix Huettner<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Ignazio Cassano <ignaziocassano@gmail.com> <br>
<b>Sent:</b> Wednesday, August 3, 2022 12:28 PM<br>
<b>To:</b> openstack-discuss <openstack-discuss@lists.openstack.org><br>
<b>Subject:</b> [openstack] how to speed up live migration?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hello All,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I am looking for a solution to speed up live migration.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Instances where ram is used heavily like java application servers, live migration take a long time (more than 20 minutes for 8GB ram instance) and converge mode is already set to True in nova.conf.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I also tried with post_copy but it does not change.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">After the first live migration (very solow) if I try to migrate again it is very fast.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I presume the first migration is slow because memory fragmentation when an instance is running on the same compute node for a long time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I am looking for a solution considering the on my computing node I can have
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span class="gmail-q4iawc"><span lang="EN">a little ram overcommit. Any case I am increasing the number of compute nodes to reduce it.</span></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ignazio<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p style="font-family:Calibri;font-size:11pt">Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte
unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie
<a href="https://www.datenschutz.schwarz">hier</a>.</p>
</body>
</html>