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(a)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(a)redhat.com>
--
/kashyap