Re: Discussion: Add API to retrieve migration progress

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2013-11-13 at 01:23 -0700, Chun Yan Liu wrote:
> 
> >>> On 11/12/2013 at 07:16 PM, in message
> <1384255004.1883.54.camel@kazak.uk.xensource.com>, Ian Campbell
> <Ian.Campbell@citrix.com> wrote: 
> > On Tue, 2013-11-12 at 11:05 +0000, George Dunlap wrote: 
> > > On Fri, Nov 8, 2013 at 11:13 AM, Andrew Cooper 
> > > <andrew.cooper3@citrix.com> wrote: 
> > > > 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. 
> > >  
> > > I don't think people necessarily want a 100% accurate prediction; they 
> > > just want an idea how far along things are going (and a reassurance 
> > > that things are actually moving).  I think if the algorithm assumes 2 
> > > passes and then a clean-up phase, and just hard-codes in assumptions 
> > > about what percentage each pass will take (e.g., 80% for first pass, 
> > > 15% for 2nd pass, 5% for final clean-up), the results will be useful, 
> > > and about as accurate as anyone can expect. 
> >  
> > Note that the existing code has some algorithm, or at least it is 
> > calling xc_report_progress_step with some numbers. Whatever it is is 
> > probably "good enough". 
> >  
> 
> Well, I think the problem is not that the log information is enough or not, but
> that sometimes it's not convenient if we only have logs. We may need a function
> like 'query-migrate' as qemu does, so that we could actively check migrate 
> progress or status at any time during migration, and based on this, we could 
> supply user progress bar or whatever.

Why is the xentoollog_logger.progress callback insufficient for this
use?

If you wanted to then the application (be that xl or libvirt) could just
stash the most recent progress and provide an API to the rest of the ap.

Ian.