RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1197592 - blockcopy always failed when with option "--pivot"
Summary: blockcopy always failed when with option "--pivot"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Virtualization Bugs
Yehuda Zimmerman
URL:
Whiteboard:
Depends On:
Blocks: 1288337 1305606 1313485
TreeView+ depends on / blocked
 
Reported: 2015-03-02 07:37 UTC by Shanzhi Yu
Modified: 2016-11-03 18:13 UTC (History)
12 users (show)

Fixed In Version: libvirt-1.3.2-1.el7
Doc Type: Release Note
Doc Text:
"blockcopy" with "--pivot" option no longer fails Previously, "blockcopy" always failed when the "--pivot" option was specified. With this release, the _libvirt_ package was updated to prevent this issue. "blockcopy" can now be used with the "--pivot" option.
Clone Of:
Environment:
Last Closed: 2016-11-03 18:13:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2577 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Description Shanzhi Yu 2015-03-02 07:37:29 UTC
Description of problem:

blockcopy always failed when with option "--pivot"

Version-Release number of selected component (if applicable):

kernel-3.10.0-230.el7.x86_64
libvirt-1.2.8-16.el7_1.1.x86_64
qemu-kvm-rhev-2.2.0-5.el7.x86_64

How reproducible:

always

Steps to Reproduce:
1. Prepare a transient guest with OS installed
# virsh list --transient
 Id    Name                           State
----------------------------------------------------
 170   r7                             running


2. Do blockcopy with option "--pivot"
#virsh blockcopy r7 vda /var/lib/libvirt/images/r7.clone --pivot --verbose --wait
Block Copy: [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

3.

Actual results:

It's not 100% reproduced, but always failed.

Expected results:


Additional info:

1. I can't reproduce it if I use a guest without installed OS.
2. It will not fail if finish the blockcopy with "--pivot" option after several seconds when the guest is in mirror phrase.

Do pivot at once when guest in mirror phrase

# for i in {1..10};do virsh create r7.xml; sleep 30;virsh blockcopy r7 vda /var/lib/libvirt/images/r7.clone --pivot --verbose --wait;virsh destroy r7;rm -fr /var/lib/libvirt/images/r7.clone;sleep 5; done 
Domain r7 created from r7.xml

Block Copy: [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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Do pivot after several seconds when guest in mirror phrase

# for i in {1..10};do virsh create r7.xml; sleep 15;virsh blockcopy r7 vda /var/lib/libvirt/images/r7.clone --verbose --wait;sleep 5;virsh blockjob r7 vda --pivot; virsh destroy r7;rm -fr /var/lib/libvirt/images/r7.clone; done 
Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

This result is based many cycles running above script.

Comment 2 Eric Blake 2015-04-14 20:34:54 UTC
I'm trying to figure out what is going wrong here. In my local reproduction test case, at one point I ran out of disk space, which results in qemu aborting the job with BLOCK_JOB_ERROR, but libvirt is not looking to receive that error.  Is your test setup something that could be failing due to low disk space, as that would give the same symptoms I saw, or is it something else?

Comment 3 Eric Blake 2015-04-14 21:39:28 UTC
Your libvirt is new enough that you could use 'virsh qemu-monitor-event $dom --pretty --loop' in a second window to see if any unexpected qemu events are being ignored by libvirt when they shouldn't be (I'm also trying that locally).

Comment 4 Shanzhi Yu 2015-04-16 07:44:33 UTC
(In reply to Eric Blake from comment #2)
> I'm trying to figure out what is going wrong here. In my local reproduction
> test case, at one point I ran out of disk space, which results in qemu
> aborting the job with BLOCK_JOB_ERROR, but libvirt is not looking to receive
> that error.  Is your test setup something that could be failing due to low
> disk space, as that would give the same symptoms I saw, or is it something
> else?

No, I am sure there is enough disk space, and, nothing particular. 

(In reply to Eric Blake from comment #3)
> Your libvirt is new enough that you could use 'virsh qemu-monitor-event $dom
> --pretty --loop' in a second window to see if any unexpected qemu events are
> being ignored by libvirt when they shouldn't be (I'm also trying that
> locally).

Ok then, I prepare xml file r7.xml and a qcow2 image with OS installed.
then I do below test:

terminal I:

#  for i in {1..10};do virsh create r7.xml; sleep 1;virsh blockcopy r7 vda /var/lib/libvirt/images/r7.clone --pivot --verbose --wait;virsh destroy r7;rm -fr /var/lib/libvirt/images/r7.clone;sleep 1; done 
Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Domain r7 created from r7.xml

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

Domain r7 destroyed

Domain r7 created from r7.xml

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

Domain r7 destroyed

Domain r7 created from r7.xml

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

Domain r7 destroyed

Domain r7 created from r7.xml

Block Copy: [100 %]
Successfully pivoted
Domain r7 destroyed

Terminal II:

# virsh   qemu-monitor-event r7  --pretty --loop
event BLOCK_JOB_READY at 1429169902.165004 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169902.405104 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169902.412935 for domain r7: <null>
event RESUME at 1429169919.016565 for domain r7: <null>
event BLOCK_JOB_READY at 1429169923.843333 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169924.069432 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169924.077232 for domain r7: <null>
event RESUME at 1429169925.666298 for domain r7: <null>
event BLOCK_JOB_READY at 1429169930.603544 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169930.725262 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169930.734993 for domain r7: <null>
event RESUME at 1429169932.309771 for domain r7: <null>
event BLOCK_JOB_READY at 1429169937.299802 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169937.377559 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169937.390576 for domain r7: <null>
event RESUME at 1429169938.933651 for domain r7: <null>
event BLOCK_JOB_READY at 1429169943.904885 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169943.991670 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169943.999019 for domain r7: <null>
event RESUME at 1429169945.563332 for domain r7: <null>
event BLOCK_JOB_READY at 1429169950.353163 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169950.635630 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169950.644113 for domain r7: <null>
event RESUME at 1429169952.194842 for domain r7: <null>
event BLOCK_JOB_READY at 1429169957.123371 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169957.251146 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169957.258473 for domain r7: <null>
event RESUME at 1429169958.809844 for domain r7: <null>
event SHUTDOWN at 1429169959.860556 for domain r7: <null>
event RESUME at 1429169961.723367 for domain r7: <null>
event SHUTDOWN at 1429169962.775693 for domain r7: <null>
event RESUME at 1429169964.432833 for domain r7: <null>
event SHUTDOWN at 1429169965.502135 for domain r7: <null>
event RESUME at 1429169967.374067 for domain r7: <null>
event BLOCK_JOB_READY at 1429169972.260246 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event BLOCK_JOB_COMPLETED at 1429169972.433841 for domain r7: {
    "device": "drive-virtio-disk0",
    "len": 1223557120,
    "offset": 1223557120,
    "speed": 0,
    "type": "mirror"
}

event SHUTDOWN at 1429169972.441158 for domain r7: <null>
^Cevent loop interrupted
events received: 37

Comment 5 Shanzhi Yu 2015-06-23 10:25:24 UTC
Hi Eric,

I always met below error even through I separate the blockcopy to two phase. 

"error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed"

First I do blockcopy, then finish the blockjob with "blockjob --pivot", but still met the error. 

Steps: 
1. Prepare a xml file and storage file installed with rhel7 OS. 
2. Do cycle blockcopy. 

#j=0;for i in {1..100};do virsh create r7.xml;sleep 20;virsh blockcopy r7 vda /var/lib/libvirt/images/r7-$i.cp  --verbose --wait;virsh blockjob r7 vda --pivot; a=$?; if [[ $a -eq 0 ]]; then let j=j+1 ;fi; virsh destroy r7 ;rm -fr /var/lib/libvirt/images/r7-$i.cp;done ; echo $j; 
Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase
error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed

Domain r7 destroyed

Domain r7 created from r7.xml

...

...

Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

83

So there're 17 failed cases in this testing. 

But If I wait seconds after mirror phase, then finish the blockcopy job with --pivot, I could not meet the error again. same script as in step 2. Just add "sleep 5" before "virsh blockjob r7 vda --pivot". 

j=0;for i in {1..100};do virsh create r7.xml;sleep 20;virsh blockcopy r7 vda /var/lib/libvirt/images/r7-$i.cp  --verbose --wait;sleep 5;virsh blockjob r7 vda --pivot; a=$?; if [[ $a -eq 0 ]]; then let j=j+1 ;fi; virsh destroy r7 ;rm -fr /var/lib/libvirt/images/r7-$i.cp;done ; echo $j;

Domain r7 created from r7.xml

Block Copy: [100 %]
Now in mirroring phase
...
...
Block Copy: [100 %]
Now in mirroring phase

Domain r7 destroyed

100

The cases 100 percent pass in this testing.
Does this bug related with qemu bug 1130489 - qemu do not close src image immediately after mirroring done ?
Should this bug got a fix ASAP?


BTW, I do above testing with upstream qemu and libvirt

# virsh --version 
1.3.0
# qemu-kvm --version 
QEMU emulator version 2.3.0 (qemu-2.3.0-10.fc22), Copyright (c) 2003-2008 Fabrice Bellard

Comment 6 Peter Krempa 2015-07-16 06:47:31 UTC
The problem lies in the fact that qemu does not switch internally to the synchronised phase as soon as the cursors hit 100% (info.cur == info.end), but it might take a while. In qemu 2.2 a new field was introduced in the query-block-jobs output that notes when the block job is ready.

Since libvirt expected that once the job hit 100% it was switched to synchronised even before we received the event we allowed to send the block-job-complete command to qemu without reporting the proper error.

Additionally virsh needs a fix where we need to wait for the event before attempting to pivot.

I've posted a series that should fix this problem along with others so I'm reassigning the bug to myself.

Comment 7 Shanzhi Yu 2015-07-16 08:48:39 UTC
I give a simple test with patch series "[libvirt] [PATCH 00/13] Improve virsh block job handling"
# git describe 
v1.2.17-130-ga864149

As steps in comment 5, it works fine.

Thanks

Comment 8 Peter Krempa 2015-07-21 13:44:05 UTC
Fixed upstream:

commit faa143912381aa48e33839b194b32cc14d574589
Author: Peter Krempa <pkrempa>
Date:   Mon Jul 13 17:04:49 2015 +0200

    virsh: Refactor block job waiting in cmdBlockCopy
    
    Similarly to the refactor of cmdBlockCommit in a previous commit this
    does the same change for cmdBlockCopy.

commit 7408403560f7d054da75acaab855a95c51a92e2b
Author: Peter Krempa <pkrempa>
Date:   Mon Jul 13 17:04:49 2015 +0200

    virsh: Refactor block job waiting in cmdBlockCommit
    
    Reuse the vshBlockJobWait infrastructure to refactor cmdBlockCommit to
    use the common code. This additionally fixes a bug when working with
    new qemus, where when doing an active commit with --pivot the pivoting
    would fail, since qemu reaches 100% completion but the job doesn't
    switch to synchronized phase right away.

commit 2e7827636476fdf976f17cd234b636973dedffc0
Author: Peter Krempa <pkrempa>
Date:   Mon Jul 13 17:04:49 2015 +0200

    virsh: Refactor block job waiting in cmdBlockPull
    
    Introduce helper function that will provide logic for waiting for block
    job completion so the 3 open coded places can be unified and improved.
    
    This patch introduces the whole logic and uses it to fix
    cmdBlockJobPull. The vshBlockJobWait function provides common logic for
    block job waiting that should be robust enough to work across all
    previous versions of libvirt. Since virsh allows passing user-provided
    strings as paths of block devices we can't reliably use block job events
    for detection of block job states so the function contains a great deal
    of fallback logic.

commit eae59247c59aa02147b2b4a50177e8e877fdb218
Author: Peter Krempa <pkrempa>
Date:   Wed Jul 15 15:11:02 2015 +0200

    qemu: Update state of block job to READY only if it actually is ready
    
    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


v1.2.17-142-gfaa1439

Comment 11 Yang Yang 2015-08-25 09:56:01 UTC
Peter,

Regarding the problem that virsh still reports error when doing blockcopy (or blockcommit) with option pivot, is it able to be fixed in libvirt side? If YES, do you need a new bug to track it?

# virsh blockcopy rhel7.0 vda /tmp/f.img --wait --verbose --pivot
Block Copy: [100 %]error: failed to pivot job for disk vda
error: block copy still active: disk 'vda' not ready for pivot yet


# virsh blockcommit rhel7.0 vda --active --wait --verbose --pivot
Block Copy: [100 %]error: failed to pivot job for disk vda
error: block copy still active: disk 'vda' not ready for pivot yet

Comment 12 Peter Krempa 2015-09-08 13:29:11 UTC
The output above looks like patch "qemu: Update state of block job to READY only if it actually is ready" was applied, but none of the others were. Since this requires a client-side fix, did you update the client machine too?

Comment 13 Yang Yang 2015-09-09 10:04:38 UTC
libvirt and libvirt-client I used are latest versions. I still have the problem.
# rpm -qa | grep libvirt
libvirt-1.2.17-8.el7.x86_64
libvirt-client-1.2.17-8.el7.x86_64

Comment 14 Yang Yang 2015-09-23 10:12:27 UTC
Peter, 
According to comment #11,#12,#13, I re-assign it. Please feel free to correct me if I'm wrong.

Comment 17 Nerijus Baliūnas 2015-10-30 13:28:50 UTC
blockcommit completes successfully if I change virtual disk Cache mode from
Hypervisor default to none. If not, almost every time for a bigger disk I get:
Block commit: [100 %]error: failed to pivot job for disk vda
error: block copy still active: disk 'vda' not ready for pivot yet

Comment 19 Nerijus Baliūnas 2015-12-08 10:42:18 UTC
Even with "Cache mode" none blockcommit sometimes fails when VM has postgresql db running. Adding --quiesce to virsh snapshot-create-as and installing qemu-guest-agent helped.

Comment 20 Peter Krempa 2016-02-01 17:08:42 UTC
Another few upstream commits finally fix the issue:

commit 86c4df83b913dd73b79caeed2038291374384dc5
Author: Michael Chapman <mike.org>
Date:   Wed Jan 27 13:24:54 2016 +1100

    virsh: improve waiting for block job readiness
    
    After a block job hits 100%, we only need to apply a timeout waiting for
    a block job event if exactly one of the BLOCK_JOB or BLOCK_JOB_2
    callbacks were able to be registered.
    
    If neither callback could be registered, there's clearly no need for a
    timeout.
    
    If both callbacks were registered, then we're guaranteed to eventually
    get one of the events. The path being used by virsh must be exactly the
    source path or target device in the domain's disk definition, and these
    are the respective strings sent back in these two events.
    
    Signed-off-by: Michael Chapman <mike.org>

commit 8fa216bbb40df33e7fce5d727aa3dc334480878a
Author: Michael Chapman <mike.org>
Date:   Wed Jan 27 13:24:53 2016 +1100

    virsh: ensure SIGINT action is reset on all errors
    
    If virTimeMillisNow() fails, the SIGINT action must be reset back to
    its previous state.
    
    Signed-off-by: Michael Chapman <mike.org>

commit 15dee2ef24f2f19f6dcd30d997b81c8a14582361
Author: Michael Chapman <mike.org>
Date:   Wed Jan 27 13:24:52 2016 +1100

    virsh: be consistent with style of loop exit
    
    When waiting for a block job, the various statuses (COMPLETED, READY,
    CANCELED, etc.) should all be treated consistently by having the loop be
    exited with "break". Use "goto cleanup" for the error cases only, when
    no block job status is available.
    
    Signed-off-by: Michael Chapman <mike.org>

commit 704dfd6b0fafe7eafca93a03793389239f8ab869
Author: Michael Chapman <mike.org>
Date:   Wed Jan 27 13:24:51 2016 +1100

    virsh: avoid unnecessary progress updates
    
    There is no need to call virshPrintJobProgress() unless the block job's
    cur or end cursors have changed since the last iteration.
    
    Signed-off-by: Michael Chapman <mike.org>

v1.3.1-87-g86c4df8

Comment 22 Yang Yang 2016-04-27 06:51:51 UTC
Verified with libvirt-1.3.3-2.el7.x86_64
1. test blockcopy
Prepare a xml, use gluster backend disk as source 
<disk type='network' device='disk'>
      <driver name='qemu' type='qcow2' io='threads' ioeventfd='on' event_idx='off'/>
      <source protocol='gluster' name='gluster-vol1/rhel7.qcow2'>
        <host name='10.66.4.164'/>
      </source>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</disk>

# virsh create vm5.xml 
Domain vm5 created from vm5.xml

1.1 test blockcopy & pivot job
# virsh blockcopy vm5 vda /tmp/vm5.copy --wait --verbose --pivot
Block Copy: [100 %]
Successfully pivoted

# virsh dumpxml vm5 | grep disk -a6
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' io='threads' ioeventfd='on' event_idx='off'/>
      <source file='/tmp/vm5.copy'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>

1.2 test blockcopy & blockdev & pivot job
# virsh destroy vm5
Domain vm5 destroyed

# virsh create vm5.xml 
Domain vm5 created from vm5.xml

# virsh blockcopy vm5 vda /dev/sdl --blockdev --wait --verbose --pivot
Block Copy: [100 %]
Successfully pivoted

 <disk type='block' device='disk'>
      <driver name='qemu' type='qcow2' io='threads' ioeventfd='on' event_idx='off'/>
      <source dev='/dev/sdl'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>

1.3 test blockcopy & cancel job
# virsh blockcopy vm5 vda /tmp/vm5.copy --wait --verbose --pivot
Block Copy: [ 16 %]^C
Copy aborted

2. test blockcommit
Prepare a running vm with following xml
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/RHEL-7.2-20151008.0.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>

# virsh snapshot-create-as vm1 s1 --disk-only --quiesce
Domain snapshot s1 created

# virsh snapshot-create-as vm1 s2 --disk-only --quiesce
Domain snapshot s2 created

# virsh snapshot-create-as vm1 s3 --disk-only --quiesce
Domain snapshot s3 created

2.1 test blockcommit & pivot job
# virsh blockcommit vm1 vda --active --wait --verbose --pivot --shallow
Block commit: [100 %]
Successfully pivoted

<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/RHEL-7.2-20151008.0.s2'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/libvirt/images/RHEL-7.2-20151008.0.s1'/>
        <backingStore type='file' index='2'>
          <format type='qcow2'/>
          <source file='/var/lib/libvirt/images/RHEL-7.2-20151008.0.qcow2'/>
          <backingStore/>
        </backingStore>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>

2.2. test blockcommit & abort job
# virsh blockcommit vm1 vda --active --wait --verbose --pivot --timeout 1
Block commit: [ 88 %]
Commit aborted

blockcopy and blockcommit work well, move it to verified status

Comment 26 errata-xmlrpc 2016-11-03 18:13:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html


Note You need to log in before you can comment on or make changes to this bug.