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:

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