Re: [Xen-devel] Discussion: Add API to retrieve migration progress

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-11-13 at 02:47 -0700, Chun Yan Liu wrote:
> 
> >>> On 11/13/2013 at 04:27 PM, in message
> <1384331255.25822.1.camel@xxxxxxxxxxxxxxxxxxxx>, Ian Campbell
> <Ian.Campbell@xxxxxxxxxx> wrote: 
> > 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@xxxxxxxxxxxxxxxxxxxxxx>, Ian Campbell 
> > > <Ian.Campbell@xxxxxxxxxx> 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@xxxxxxxxxx> 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.  
> 
> Yes, that is just what we want. We could make use of the
> xentoollog_logger.progress callback, output the progress info to lg->file, 
> meanwhile store the progress details (context, doing what, done, total, etc.) 
> somewhere and provide an API to get those info for the rest. If I know 
> correctly, only save/restore uses .progress callback, so we could do some 
> changes in stdiostream_progress, and provide API in libxl. Libvirt could then 
> use the logger and API.

Wouldn't you want libvirt to have its own logger which directs
everything to the standard libvirt logging infrastructure?

You are under no obligation to use the stdiostream logger if you don't
want to. Indeed I think it would make sense for libvirt to have its own.

Ian.


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