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

Re: [libvirt] [PATCH] qemu: blockjob: Don't report block job progress at 100% if job isn't ready



On Tue, Jan 29, 2019 at 18:52:37 +0100, Kashyap Chamarthy wrote:
> On Tue, Jan 29, 2019 at 05:24:09PM +0100, Peter Krempa wrote:
> > Some clients take the advice to poll virDomainGetBlockJobInfo rather
> > than wait for the ready event. In some cases qemu can get to 100% and
> > still not reach the synchronised phase.
> > 
> > Since we are dealing with a computer interacting, 
> 
> OCD nit: The above sounds awkward to me, might want to rephrase it,
> maybe something like: "Given that computers are interacting here ..."
> 
> > the error that the job
> > can't be finalized yet is not handled very well by those specific
> > implementations.
> > 
> > Our docs now correctly state to use the event.
> 
> Nit: Calling out the event name, VIR_DOMAIN_BLOCK_JOB_READY can be
> useful when reading Git logs at a later time.
> 
> > We already munge the output for the start of the job, so we can do it
> > even here.
> 
> Optional, a bit of explanation of "munging the output" at the start (and
> end) of the job would be useful for those new to these block APIs.
> 
> Reading between the lines, and from what I recall Eric explaining once,
> what you're implying here is: that even if QEMU reported "cur==end", but
> if the _READY event is not emitted, libvirt manipulates it to report
> "cur<end".
> 
> Thanks for the workaround (because "QEMU is not accurately reporting
> data") fix.
> 
> /me wonders if he could make a reliable reproducer test for this...

Technically you'll need to patch either libvirt or qemu to do so. E.g.
add a delay to processing of the READY event from qemu. This is a race
across two applications which is not easy to reproduce.

Also I really don't want to think this is a solution. This is a dirty
hack to work around software not willing to adapt to the correct
approach.

I did not want do do this, but I've found that we do something similar
for the job startup. I really hate this solution, but given that it's two years since
I've pointed out that relying on polling the info via
virDomainBlockJobInfo is broken and apps should use the _READY event and
it's still an issue today I'm going to do this, but really don't want to
advertise this as a solution. It's not a solution. It's a hack.

Attachment: signature.asc
Description: PGP signature


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