On 01/13/2015 07:21 AM, Kashyap Chamarthy wrote:> On Tue, Jan 13, 2015 at 03:07:07PM +0100, Fiorenza Meini wrote: >> Il 13/01/2015 10:51, Kashyap Chamarthy ha scritto: > > [. . .] > >>>> In libvirt log file I can see: >>>> error : qemuDomainDefineXML:6312 : block copy still active: domain has >>>> active block job> > 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 > backgroundThat was against RHEL 7; but I don't know if any Fedora releases suffer from the same issue. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
Il 13/01/2015 16:56, Kashyap Chamarthy ha scritto:> 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> >I'm working on Debian Wheezy, upgrading to 1.29 libvirt version libvirtd service doesn't start any more, so at the moment it isn't upgradable.... Regards Fiorenza Meini -- Spazio Web S.r.l. V. Dante, 10 13900 Biella Tel.: +39 015 2431982 Fax.: +39 015 2522600 Numero d'Iscrizione al Registro Imprese presso CCIAA Biella, Cod.Fisc.e P.Iva: 02414430021 Iscriz. REA: BI - 188936 Cap. Soc.: €. 30.000 i.v.