Re: [libvirt] should active block commit ever be allowed to show 0 total progress?

I was trying to work on a libvirt bug, when I discovered the following: $ qemu-img create -f qcow2 a.qcow2 10M Formatting 'a.qcow2', fmt=qcow2 size=10485760 encryption=off cluster_size=65536 lazy_refcounts=off $ qemu-img create -f qcow2 \ -obacking_file=a.qcow2,backing_fmt=qcow2 b.qcow2 Formatting 'b.qcow2', fmt=qcow2 size=10485760 backing_file='a.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off $ qemu-img create -f qcow2 \ -obacking_file=b.qcow2,backing_fmt=qcow2 c.qcow2 Formatting 'c.qcow2', fmt=qcow2 size=10485760 backing_file='b.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off $ qemu-kvm -nodefaults -qmp stdio c.qcow2 {"execute":"qmp_capabilities"} {"execute":"block-commit","arguments":{"device":"ide0-hd0","top":"c.qcow2","base":"b.qcow2"}} Note that it gives me the following event practically right away: {"timestamp": {"seconds": 1421101221, "microseconds": 47075}, "event": "BLOCK_JOB_READY", "data": {"device": "ide0-hd0", "len": 0, "offset": 0, "speed": 0, "type": "commit"}} and that a "query-block-jobs" confirms the "len":0,"offset":0 reporting. That is, because c.qcow2 has no sectors that differ from b.qcow2, the two files are immediately in sync. But what is annoying is that it claims that 'len' and 'offset' are equal at zero, while libvirt has code that special cases both numbers as 0 as meaning that the job has not yet started. I can fix libvirt to treat len==offset==0 as treating a job as 100% complete, but I'm wondering if qemu should be fixed to always report a non-zero length for every job that has successfully started, in order to reserve the case of a zero length for a job that has not yet determined how much needs to be done and can be treated as 0% complete. That is, does qemu have a bug for making it possible to confuse libvirt on whether a copy or active commit job has entered the second phase in contrast to not knowing if the job has started yet?