[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v2 12/12] qemu: show disks stats for nbd migration

On Fri, Feb 17, 2017 at 17:30:27 +0300, Nikolay Shirokovskiy wrote:
> On 17.02.2017 13:17, Jiri Denemark wrote:
> > On Wed, Dec 28, 2016 at 17:39:21 +0300, Nikolay Shirokovskiy wrote:
> >> There is no disks stats when migrating with VIR_MIGRATE_NON_SHARED_*
> >> for qemu that supports nbd. The reason is that disks are copied via disk mirroring
> >> and not in the scope of migration job itself. Below
> >> a couble of issues of the implementation are described.
> >>
> >> 'total' field is set from 'end' field of block job info for the
> >> sake of simplicity. This is true only when there is no guest disk
> >> activity during migration. If there is an activity then 'end' will
> >> grow
> > 
> > This is exactly how memory migration works too.
> > 
> >> while 'total' is an estimation that should stay constant.
> > 
> > Nope. That's the reason why migration is an unbounded job, we never know
> > what the total is and it is designed to change anytime during migration
> > as we realize more data needs to be transferred.
> > 
> >> I guess this can be fixed by setting 'total' to disk 'capacity'.
> > 
> > Nothing to fix really.
> Then I don't understand next passage from virDomainJobInfo definition.
>      * For VIR_DOMAIN_JOB_UNBOUNDED, dataTotal may be less
>      * than the final sum of dataProcessed + dataRemaining
>      * in the event that the hypervisor has to repeat some
>      * data, such as due to dirtied pages during migration.
> I thought total is initial estimation which never changed 
> and processed and remaining are updated as we go. IIRC this is the case
> for memory migration.

Hmm. I believe total has always been updated and when watching a live
migration, one would see a progress (dataProcess / dataTotal * 100)
which looks like

    0% ... 100% ... 70% ... 100% ... 90% ... 100%

Either I'm totally wrong or the documentation does not describe reality.
There's definitely something to be fixed here :-) I'll try to dig into

> > Otherwise the patch looks good and it's definitely cleaner than v1.
> > However, I think you should also update disk migration statistics while
> > stopping the mirror jobs so that the stats of a completed migration
> > contain accurate data.
> You mean after migration is completed there can be some disks transfers yet like
> buffered data? Ok.

Exactly, when memory migration completes we need to wait for all mirror
jobs to finish to make sure all disk blocks changed on the source are
transferred to the destination. And we need to count these last moment
transfers too.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]