[libvirt] [PATCH] virsh: report 0-length active block-commit job status

[Eric Blake]

On 01/19/2015 03:01 PM, John Ferlan wrote:
> 

Revisiting, now that the release is done.

> 
> On 01/12/2015 05:54 PM, Eric Blake wrote:
>> At least with live block commit, it is possible to have a block
>> job that reports 0 status: namely, when the active image contains
>> no sectors that differ from the backing image it is being committed
>> into [1].  I'm not sure if that represents a qemu bug, but it leads
>> to weird virsh output where 'virsh blockjob $dom vda' has no output
>> during a no-op commit job.  It appears that the special case for
>> a zero total was first introduced for migration, where it does sort
>> of make sense (when we do storage migration, the job is broken up
>> into two pieces where the first half of migrating storage has no
>> clue what the total length of the second phase will be, and where
>> qemu migration always reports a non-zero total length but only once
>> we complete the first phase to start actual migration), but it
>> doesn't seem to make sense for any of the block jobs.
>>

>> @@ -1678,10 +1678,6 @@ vshPrintJobProgress(const char *label, unsigned long long remaining,
>>  {
>>      int progress;
>>
>> -    if (total == 0)
>> -        /* migration has not been started */
>> -        return;
>> -
> 
> Would it be necessarily true that remaining was zero at this point?

I've never seen a case where qemu (and thus libvirt) reported remaining
> total.

> Because if it wasn't then, the else condition will divide by zero if
> total == 0...  More than 1 caller to this function...

So I think we are safe in avoiding the divide by 0 potential.  Of the
multiple callers, many are related to block jobs (where 0 status is
likely synonymous with no work to do) and the only caller I modified
(migration) is where 0 status means not yet started.

> 
> Perhaps safer to say if "remaining == 0 || total == 0"?
> 
> I was just reviewing Michal's patch from last week:
> 
> http://www.redhat.com/archives/libvir-list/2015-January/msg00230.html
> 
> where it seems a zero could imply some sort of failure.  If you did the
> total == 0 check, then the && jobinfo.dataTotal isn't necessary...  I
> would suppose that an error would mean we're 100% done...
> 

I'm also debating whether qemu has a bug for reporting 0 (it would be
nicer if it always reserved 0 for not started, and non-zero for
completed) - but how would we tell the difference between a fixed and
broken qemu?

-- 
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://listman.redhat.com/archives/libvir-list/attachments/20150127/28addc4f/attachment-0001.sig>