<div dir="ltr"><div>Hi Paul,</div><div>Comments inline:</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">2015-11-23 16:36 GMT+08:00 Paul Carlton <span dir="ltr"><<a href="mailto:paul.carlton2@hpe.com" target="_blank">paul.carlton2@hpe.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">John<br>
<br>
At the live migration sub team meeting I undertook to look at the issue<br>
of progress reporting.<br>
<br>
The use cases I'm envisaging are...<br>
<br>
As a user I want to know how much longer my instance will be migrating<br>
for.<br>
<br>
As an operator I want to identify any migration that are making slow<br>
 progress so I can expedite their progress or abort them.<br>
<br>
The current implementation reports on the instance's migration with<br>
respect to memory transfer, using the total memory and memory remaining<br>
fields from libvirt to report the percentage of memory still to be<br>
transferred.  Due to the instance writing to pages already transferred<br>
this percentage can go up as well as down.  Daniel has done a good job<br>
of generating regular log records to report progress and highlight lack<br>
of progress but from the API all a user/operator can see is the current<br>
percentage complete.  By observing this periodically they can identify<br>
instance migrations that are struggling to migrate memory pages fast<br>
enough to keep pace with the instance's memory updates.<br>
<br>
The problem is that at present we have only one field, the instance<br>
progress, to record progress.  With a live migration there are measures<br></blockquote><div><br></div><div>[Shaohe]:</div><div><pre style="white-space:pre-wrap;word-wrap:break-word;width:1437.95px;color:rgb(0,0,0);font-size:14px;line-height:21.6364px"><div>From this link, OpenStack API ref: </div><div><span lang="EN-US" style="font-size:10pt;font-family:'Segoe UI',sans-serif"><a href="http://developer.openstack.org/api-ref-compute-v2.1.html#listDetailServers">http://developer.openstack.org/api-ref-compute-v2.1.html#listDetailServers</a></span><span lang="EN-US" style="font-size:10pt"> </span></div><div><span style="line-height:21.6364px">It describe the instance </span><span style="line-height:21.6364px">progress: </span><span style="color:rgb(83,83,83);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;line-height:18.1818px;white-space:normal;background-color:rgb(249,249,249)">A percentage value of the build progress.</span></div><div>But for libvirt driver it does be migration progress. </div><div>For other driver it is building <span style="line-height:21.6364px">progress.</span></div><div><span style="line-height:21.6364px">And there is a spec to propose some change.</span></div><div><span style="line-height:1.7"><a href="https://review.openstack.org/#/c/249086/">https://review.openstack.org/#/c/249086/</a></span></div><div><br></div></pre></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
of progress, how much of the ephemeral disks (not needed for shared<br>
disk setups) have been copied and how much of the memory has been<br>
copied. Both can go up and down as the instance writes to pages already<br>
copied causing those pages to need to be copied again.  As Daniel says<br>
in his comments in the code, the disk size could dwarf the memory so<br>
reporting both in single percentage number is problematic.<br>
<br>
We could add an additional progress item to the instance object, i.e.<br>
disk progress and memory progress but that seems odd to have an<br>
additional progress field only for this operation so this is probably<br>
a non starter!<br>
<br>
For operations staff with access to log files we could report disk<br>
progress as well as memory in the log file, however that does not<br>
address the needs of users and whilst log files are the right place for<br>
support staff to look when investigating issues operational tooling<br>
is much better served by notification messages.<br>
<br>
Thus I'd recommend generating periodic notifications during a migration<br>
to report both memory and disk progress would be useful?  Cloud<br>
operators are likely to manage their instance migration activity using<br>
some orchestration tooling which could consume these notifications and<br>
deduce what challenges the instance migration is encountering and thus<br>
determine how to address any issues.<br>
<br>
The use cases are only partially addressed by the current<br>
implementation, they can repeatedly get the server details and look at<br>
the progress percentage to see how quickly (or even if) it is<br>
increasing and determine how long the instance is likely to be<br>
migrating for.  However for an instance that has a large disk and/or<br>
is doing a high rate of disk i/o they may see the percentage complete<br>
(i.e. memory) repeatedly showing 90%+ but the instance migration does<br>
not complete.<br>
<br>
The nova spec <a href="https://review.openstack.org/#/c/248472/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/248472/</a> suggests making<br>
detailed information available via the os-migrations object.  This is<br>
not a bad idea but I have some issues with the implementation that I<br>
will share on that spec.<br></blockquote><div> </div><div>[Shaohe]:<br></div><div><pre style="white-space:pre-wrap;word-wrap:break-word;width:1437.95px;color:rgb(0,0,0);font-size:14px;line-height:21.6364px"><div><span style="line-height:1.7">About this spec, Daniel has give some comments on it, and we have updated it.</span></div><div><span style="line-height:23.8px">Maybe we can work together on it to make it more better. </span><br></div><div><br></div><div>I have worked on libvirt multi-thread compress migration for libvirt. and looks</div><div>into some live migrations performance optimizations.<span class="" style="font-weight:bold;color:rgb(53,161,212);margin-right:0.5em;font-family:Arial,sans-serif;line-height:24px;white-space:normal"></span></div><div><span style="line-height:1.7"><br></span></div><div><span style="line-height:1.7">and generate an  ideas:</span></div><div><span style="line-height:21.6364px">1. Let nova expose more live migration
details, such as the RAM statistics, xbzrle-cache status, also the information
of multi-thread compression in future, and so on. </span></div><div><span style="line-height:21.6364px">2. nova can enable auto-converge, tune
the xbzrle-cache and multi-thread compression dynamically. </span></div><div><span style="line-height:21.6364px">3. Then other project can make a good
strategy to tune the live migration base on the migration details.</span></div><div><span style="line-height:21.6364px"><br></span></div><div><br></div><div><span style="line-height:21.6364px">For example:  </span></div><div><span style="line-height:21.6364px">cache size is a performance key for</span><span style="line-height:21.6364px"> xbzrle,  the best is that the cache size are</span></div><div><span style="line-height:21.6364px">same with the guest total RAM, but this maybe not always available on host.</span></div><div>Multi-thread <span style="line-height:21.6364px;font-family:arial,sans-serif">compress level is higher is better, but it </span><span style="line-height:21.6364px;font-family:arial,sans-serif">is cpu consume,</span></div><div>Auto converge will slow down the CPU running. </div><div><span style="line-height:1.7">Seems things not always </span><span id="tran_0_1" class="" style="color:rgb(67,67,67);font-family:Arial,sans-serif;line-height:24px;white-space:normal">as</span><span style="color:rgb(67,67,67);font-family:Arial,sans-serif;line-height:24px;white-space:normal"> </span><span id="tran_0_2" class="" style="color:rgb(67,67,67);font-family:Arial,sans-serif;line-height:24px;white-space:normal">good</span><span style="color:rgb(67,67,67);font-family:Arial,sans-serif;line-height:24px;white-space:normal"> as I had </span><span id="tran_0_3" class="" style="color:rgb(67,67,67);font-family:Arial,sans-serif;line-height:24px;white-space:normal">expected</span><span style="color:rgb(67,67,67);font-family:Arial,sans-serif;line-height:24px;white-space:normal">.</span></div><div><span style="line-height:21.6364px"><br></span></div><div><p class=""><span style="line-height:21.6364px">Also we have submit a topic to summit about this idea, but not accepted.
Topic: <Towards Robust Live Migration in Dynamic Environments>
Link: </span><a href="https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/presentation/4971" style="color:rgb(19,129,68);line-height:21.6364px">https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/presentation/4971</a></p><p class="" style="line-height:21.6364px"><br></p><p class="" style="line-height:21.6364px">We looking into other hypervisor, it does not expose so many details.  </p><div>And Daniel are right.</div><div>we should not expose <span style="line-height:21.2036px">so </span><span style="line-height:21.2036px">low level QEMU specific implementation details.</span></div></div><div><span style="line-height:21.2036px"><br></span></div></pre></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-- Paul Carlton Software Engineer Cloud Services<br>
Hewlett Packard Enterprise<br>
BUK03:T242<br>
Longdown Avenue<br>
Stoke Gifford<br>
Bristol BS34 8QZ<br>
Mobile: <a href="tel:%2B44%20%280%297768%20994283" value="+447768994283" target="_blank">+44 (0)7768 994283</a><br>
Email: mailto:<a href="mailto:paul.carlton2@hpe.com" target="_blank">paul.carlton2@hpe.com</a><br>
Hewlett-Packard Enterprise Limited<br>
registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England.<br>
The contents of this message and any attachments to it are confidential and may be legally privileged.<br>
If you have received this message in error, you should delete it from your system immediately and advise the sender.<br>
To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".<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><br></div></div>