On Tue, Jan 13, 2015 at 08:49:53AM -0700, Eric Blake wrote:
On 01/13/2015 07:21 AM, Kashyap Chamarthy wrote:
[. . .]
Seems like you're hitting an old bug[1] where 'blockcopy' (or 'blockcommit') missed to execute a cleanup routine which destroys a reference to the active block operation -- resulting in the error you're seeing when you attempted to 'abort' the block operation manually.
This bug is fixed in libvirt-1.2.8 and above. I see you're using libvirt-1.2.7, if you can update libvirt in your environment, that should fix your issue.
Are you using a pre-built distro libvirt? If so, which one? We should figure out how to get that vendor to backport the right fix for this issue.
Also, I just now committed another related fix; so even the latest 1.2.11 release has an issue where libvirt can get into weird states if parallel block job attempts are made. See commit e1125ce.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1135169 -- blockcopy job was cancel by "CTRL+C" while it show there still be one block job in background
That was against RHEL 7; but I don't know if any Fedora releases suffer from the same issue.
Right, I looked for a Fedora bug before referring to it. Even the libvirt master git history refers to this bug with the fixed commit: commit 8e23e0e977fbcc4a7880e187a63c509d6e6879c6 Author: Erik Skultety <eskultet@redhat.com> Date: Thu Nov 27 13:29:42 2014 +0100 qemu: fix block{commit,copy} abort handling When a block{commit,copy} job was aborted on a domain, block job handler did not process it correctly, leaving a phantom job in the background. Any further calls to any blockjob causes "block <jobtype> still active" error. This patch fixes the blockjob handler so that it checks not only for VIR_DOMAIN_BLOCK_JOB_FAILED status, but VIR_DOMAIN_BLOCK_JOB_CANCELED status as well, followed by our existing cleanup routine. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135169 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> -- /kashyap