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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list