Open Stack

On 10/06/2016 07:58 AM, Kashyap Chamarthy wrote:
> On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote:
>> TL;DR
>> -----
>>
>> From the debug analysis of the log below, and discussion with Eric Blake
>> of upstream QEMU / libvirt resulted in the below bug report:
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
>>   virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
>>   "ready" field of `query-block-jobs`
> 
> When I raised this on libvirt mailing list[0][1], one of the upstream
> libvirt devs expressed an NACK in adjusting / "deliberately reporting
> false data in block info structure".  Similar concern was also shared by
> Matt Booth on #openstack-nova IRC.

I disagree with that sentiment.  I think it is libvirt's responsibility
to live up to libvirt's promise of virDomainGetBlockJobInfo() (namely,
LIBVIRT documents that cur==end means the job is stable; and if qemu
reports cur==end when the job is not stable, then it is libvirt that is
lying to the upper user if it does NOT munge qemu's results to be accurate).

As it is, we already patched libvirt to munge qemu's 0/0 into 0/1 when
ready:false, so munging 123/123 into 122/123 when ready:false would just
be another case of libvirt working around an infelicity of qemu.  There
is NO INHERENT MEANING to the magnitude of cur and end, nor any
requirement that end stays the same value across multiple calls to
virDomainGetBlockJobInfo() - they are ONLY useful for a relative
comparison of how much work remains to be done.  Munging the results IS
appropriate.

That said, if you are going to work with existing libvirt that does not
munge values, then yes, you either have to implement event handling or
parse XML for the ready status, as existing libvirt's
virDomainGetBlockJobInfo() is insufficient for the task.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161006/6b6d508f/attachment.pgp>