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

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> 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.

Chunyan

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


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