[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Discussion: Add API to retrieve migration progress
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |