<div dir="ltr">I understand that libvirt provides async events that are triggered once the block job reaches ready state and successfully pivots as it is reported by qemu.<div>Whats the event that is triggered and what's the handler that we have to implement?</div><div>To be more specific, I am looking for the onEVENT callback method that is invoked when the event is fired.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 6:28 PM, Kashyap Chamarthy <span dir="ltr"><<a href="mailto:kchamart@redhat.com" target="_blank">kchamart@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 28, 2016 at 01:26:12PM +0200, Ala Hino wrote:<br>
> Hi guys,<br>
><br>
> When performing live merge, in few cases, we see the following exception:<br>
<br>
</span>[...]<br>
<span class=""><br>
> libvirtError: block copy still active: disk 'vdb' not ready for pivot yet<br>
<br>
</span>You can see if the block operation is still in progress or not by doing:<br>
`sudo virsh blockjob vm1 vdb --info`.<br>
<span class=""><br>
> That exception observed in following BZs:<br>
><br>
> <a href="https://bugzilla.redhat.com/1376580" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>1376580</a><br>
> <a href="https://bugzilla.redhat.com/1397122" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>1397122</a><br>
<br>
</span>[I see, that the above are oVirt bugs.]<br>
<span class=""><br>
> I am trying to understand what this exception indicates in order to handle<br>
> it appropriately when thrown by libvirt.<br>
<br>
</span>Here's the commit that adds the above error message.  In short: Until<br>
the 'query-block-jobs' QMP command emits the flag BLOCK_JOB_READY, the<br>
copy / mirror block operation is truly not complete.<br>
<br>
<br>
    commit eae59247c59aa02147b2b4a50177e8<wbr>e877fdb218<br>
    Author: Peter Krempa <<a href="mailto:pkrempa@redhat.com">pkrempa@redhat.com</a>><br>
    Date:   Wed Jul 15 15:11:02 2015 +0200<br>
<br>
        qemu: Update state of block job to READY only if it actually is ready<br>
<br>
        Few parts of the code looked at the current progress of and assumed that<br>
        a two phase blockjob is in the _READY state as soon as the progress<br>
        reached 100% (info.cur == info.end). In current versions of qemu this<br>
        assumption is invalid and qemu exposes a new flag 'ready' in the<br>
        query-block-jobs output that is set to true if the job is actually<br>
        finished.<br>
<br>
        This patch adds internal data handling for reading the 'ready' flag and<br>
        acting appropriately as long as the flag is present.<br>
<br>
        While this still doesn't fix the virsh client problem with two phase<br>
        block jobs and the --pivot option, it at least improves the error<br>
        message:<br>
<br>
        $ virsh blockcommit  --wait --verbose vm vda  --base vda[1] --active --pivot<br>
        Block commit: [100 %]error: failed to pivot job for disk vda<br>
        error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed<br>
<br>
        to<br>
<br>
        $ virsh blockcommit  --wait --verbose VM vda  --base vda[1] --active --pivot<br>
        Block commit: [100 %]error: failed to pivot job for disk vda<br>
        error: block copy still active: disk 'vda' not ready for pivot yet<br>
<br>
<br>
[...]<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
/kashyap<br>
</font></span></blockquote></div><br></div>