From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Discussion: Add API to retrieve migration progress Date: Fri, 8 Nov 2013 11:13:13 +0000 Message-ID: <527CC749.6000001@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3504569997284141025==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Chunyan Liu Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --===============3504569997284141025== Content-Type: multipart/alternative; boundary="------------060801050207030104080805" --------------060801050207030104080805 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 08/11/13 08:05, Chunyan Liu wrote: > Hi, list, > > One customer requests that we should show migration progress bar in > 'xl migrate' or 'virsh migrate', like '-h/--hash' option in 'rpm' > command, so that they could see clearly what happened in migration > period. To deal with that, we need to have a method to retrieve > migration progress. And we hope such stuff could be finally merged to > upstream. How do you think? There is no sensible way to determine timing here. A non-live migrate can be approximated based solely %age of ram transmitted. However, with a live migrate, the actions of the live guest affect how long the following iteration takes, and the longer an iteration takes, the more likely it is that further iterations will be needed later. Over the timescales required to live migrate a sensibly sized guest, changed in workload in dom0 can make a meaningful difference in time taken to send an iteration, meaning the live guest can dirty more ram and cause a larger next iteration. ~Andrew > > Besides, currently, there is some debug messages about the transferred > pages and remaining dirty pages in libxc xc_domain_save, but that > could not be reported to upper layer. We may need a libxl API, which > could save the migration status (that could be libxc passed to libxl > through pipe or other way); and may need an asyncprogress callback to > handle the async thing. Do you have any prefers about how it will be like? > > Regards, > Chunyan > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------060801050207030104080805 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

On 08/11/13 08:05, Chunyan Liu wrote:

Hi, list,

One customer requests that we should show migration progress bar in 'xl migrate' or 'virsh migrate', like '-h/--hash' option in 'rpm' command, so that they could see clearly what happened in migration period. To deal with that, we need to have a method to retrieve migration progress. And we hope such stuff could be finally merged to upstream. How do you think?

There is no sensible way to determine timing here.

A non-live migrate can be approximated based solely %age of ram transmitted. However, with a live migrate, the actions of the live guest affect how long the following iteration takes, and the longer an iteration takes, the more likely it is that further iterations will be needed later. Over the timescales required to live migrate a sensibly sized guest, changed in workload in dom0 can make a meaningful difference in time taken to send an iteration, meaning the live guest can dirty more ram and cause a larger next iteration.

~Andrew

Besides, currently, there is some debug messages about the transferred pages and remaining dirty pages in libxc xc_domain_save, but that could not be reported to upper layer. We may need a libxl API, which could save the migration status (that could be libxc passed to libxl through pipe or other way); and may need an asyncprogress callback to handle the async thing. Do you have any prefers about how it will be like?

Regards,

Chunyan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060801050207030104080805-- --===============3504569997284141025== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3504569997284141025==--