[libvirt] [PATCH 10/13] qemu: Update state of block job to READY only if it actually is ready

[Eric Blake]

On 07/15/2015 10:33 AM, Peter Krempa wrote:
> Few parts of the code looked at the current progress of and assumed that
> a two phase blockjob is in the _READY state as soon as the progress
> reached 100% (info.cur == info.end). In current versions of qemu this
> assumption is invalid and qemu exposes a new flag 'ready' in the
> query-block-jobs output that is set to true if the job is actually
> finished.
> 
> This patch adds internal data handling for reading the 'ready' flag and
> acting appropriately as long as the flag is present.
> 
> While this still doesn't fix the virsh client problem with two phase
> block jobs and the --pivot option, it at least improves the error
> message:
> 
> $ virsh blockcommit  --wait --verbose vm vda  --base vda[1] --active --pivot
> Block commit: [100 %]error: failed to pivot job for disk vda
> error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed
> 
> to
> 
> $ virsh blockcommit  --wait --verbose VM vda  --base vda[1] --active --pivot
> Block commit: [100 %]error: failed to pivot job for disk vda
> error: block copy still active: disk 'vda' not ready for pivot yet

Thanks for working on this.

I think part of the problem is that newer qemu races, and can report
info.cur == info.end == 0 very early in the process before starting to
report non-zero info.end, but info.ready is correctly false in that point.

You're right that this doesn't solve virsh racing when it sees info.cur
== info.end as a potential job complete condition (where special-casing
0 then runs into problems for no-op jobs where there really is no work
to do and the job can end instantly), but using the extra information
from qemu does look like an improvement.

-- 
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/20150720/6706ee71/attachment-0001.sig>