Fix included in qemu-kvm-rhev-2.10.0-21.el7_5.1

Reproduced block-commit issue on qemu-kvm-rhev-2.10.0-16.el7.x86_64:

Steps:
1. qemu-img create -f qcow2 -b /home/rhel75-64-virtio-scsi.qcow2 /home/snapshot1 20G
2. qemu-img create -f qcow2 -b /home/rhel75-64-virtio-scsi.qcow2 /home/snapshot2 20G
3. qemu-img create -f qcow2 -b /home/snapshot2 /home/snapshot2_2 20G

4. Launch guest A with /home/snapshot1, produce a write lock:
 /usr/libexec/qemu-kvm  \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0     \
-drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/snapshot1  \
-device scsi-hd,id=image1,drive=drive_image1

5. Launch guest B with /home/snapshot2_2:
/usr/libexec/qemu-kvm \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x3     \
-drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/snapshot2_2 \
-device scsi-hd,id=image1,drive=drive_image1     \
-qmp stdio
 
6. Execute block-commit for /home/snapshot2_2, on guest B:
{ "execute": "block-commit","arguments":{"device":"drive_image1","base":"/home/snapshot2"}}

Result:
Step 6 failed with:
{"error": {"class": "GenericError", "desc": "Failed to get \"write\" lock"}}


Verified with qemu-kvm-rhev-2.10.0-21.el7_5.1.x86_64:
Steps same as above.
Result:
Commit success:
{"timestamp": {"seconds": 1521096294, "microseconds": 623962}, "event": "BLOCK_JOB_READY", "data": {"device": "drive_image1", "len": 4521984, "offset": 4521984, "speed": 0, "type": "commit"}}
{ "execute": "block-job-complete", "arguments": { "device": "drive_image1"}}
{"return": {}}
{"timestamp": {"seconds": 1521096306, "microseconds": 203511}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive_image1", "len": 6815744, "offset": 6815744, "speed": 0, "type": "commit"}}

Based on the result, block-commit issue has been fixed.

Verified the bug as below:

Packages tested:
qemu-kvm-rhev-2.10.0-21.el7_5.1
kernel-3.10.0-860.el7.x86_64

Test steps:
Create base and snapshot as blow. Also create temporary files for each image
Create image as chain: 
base -> chain1_sn1.qcow2 -> chain1_sn2.qcow2
# qemu-img create -f qcow2 base.qcow2 20G
# qemu-img create -f qcow2 -b base.qcow2 -F qcow2 chain1_sn1.qcow2
# qemu-img create -f qcow2 -b chain1_sn1.qcow2 -F qcow2 chain1_sn2.qcow2

During the image chain1_sn2.qcow2 is booted, create image as chain:
base -> chain2_sn1.qcow2 -> chain2_sn2.qcow2 -> chain2_sn3.qcow2
# qemu-img create -f qcow2 -b base.qcow2 -F qcow2 chain2_sn1.qcow2
# qemu-img create -f qcow2 -b chain2_sn1.qcow2 -F qcow2 chain2_sn2.qcow2
# qemu-img create -f qcow2 -b chain2_sn2.qcow2 -F qcow2 chain2_sn3.qcow2

Scenario 1: Boot base image and commit snapshot, the operation should be rejected by image locking.
1.1 Boot base.qcow2 
1.2 commit snapshot
# qemu-img commit -p -t none -b chain1_sn1.qcow2 chain1_sn2.qcow2
qemu-img: Could not open 'chain1_sn2.qcow2': Could not open backing file: Could not open backing file: Failed to get shared "write" lock
Is another process using the image?

Scenario 2: Boot base image and rebase snapshot, the operation should be rejected by image locking.
2.1 Boot base.qcow2 
2.2 Rebase snapshot
# qemu-img rebase -p -f qcow2 -b chain2_sn1.qcow2 -F qcow2 chain2_sn3.qcow2 
qemu-img: Could not open 'chain2_sn3.qcow2': Could not open backing file: Could not open backing file: Could not open backing file: Failed to get shared "write" lock
Is another process using the image?

Scenario 3: Boot base image and convert snapshot, the operation should be rejected by image locking.
3.1 Boot base.qcow2 
3.2 Convert snapshot
# qemu-img convert -p -f qcow2 chain2_sn3.qcow2 -O qcow2 new.qcow2
qemu-img: Could not open 'chain2_sn3.qcow2': Could not open backing file: Could not open backing file: Could not open backing file: Failed to get shared "write" lock
Is another process using the image?
# qemu-img convert -p -f qcow2 chain1_sn2.qcow2 -O qcow2 new.qcow2
qemu-img: Could not open 'chain1_sn2.qcow2': Could not open backing file: Could not open backing file: Failed to get shared "write" lock
Is another process using the image?

Scenario 4: Boot image in snapshot chain1, all the images could be checked except the booted image
4.1 Boot chain1_sn2.qcow2
4.2 Check the image
chain1_sn1.qcow2 base.qcow2 chain2_sn1.qcow2 chain2_sn2.qcow2 chain2_sn3.qcow2 could be checked
# qemu-img check chain1_sn2.qcow2 
qemu-img: Could not open 'chain1_sn2.qcow2': Failed to get shared "write" lock
Is another process using the image?

Scenario 5: Boot image in snapshot chain1, check images in snapshot chain2 could be booted
1. Boot chain1_sn2.qcow2
2. Boot all the images and get below results.
chain1_sn2.qcow2 chain1_sn1.qcow2 base.qcow2 could not be booted
chain2_sn1.qcow2 chain2_sn2.qcow2 chain2_sn3.qcow2

Scenario 6: Boot image in snapshot chain1, commit in snapshot chain2 could be executed.
6.1 boot chain1_sn2.qcow2
6.2 commit changes
# qemu-img commit -p -f qcow2 -t none -b chain2_sn2.qcow2 chain2_sn3.qcow2 
    (100.00/100%)
Image committed.
# qemu-img info --backing-chain chain2_sn3.qcow2 
image: chain2_sn3.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 520M    ------> size doesn't empty as the design of "commit -b" 
cluster_size: 65536
backing file: chain2_sn2.qcow2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: chain2_sn2.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.0G
cluster_size: 65536
backing file: chain2_sn1.qcow2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: chain2_sn1.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 521M
cluster_size: 65536
backing file: base.qcow2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: base.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.8G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

6.3 Boot chain2_sn2.qcow2, temporary file was committed.

6.4 Commit the changes to base image, operation should be rejected by image locking.
# qemu-img commit -p -f qcow2 -t none -b base.qcow2 chain2_sn3.qcow2
    (0.00/100%)
qemu-img: Failed to get "write" lock
Is another process using the image?

Scenario 7: Boot the image in snapshot chain 1, and then rebase snapshot in snapshot chain 2.
7.1 Boot chain1_sn2.qcow2
7.2 rebase snapshot
# qemu-img rebase -p -t none -f qcow2 -b base.qcow2 -F qcow2 chain2_sn3.qcow2 
    (100.00/100%)
# qemu-img info --backing-chain chain2_sn3.qcow2 
image: chain2_sn3.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.5G
cluster_size: 65536
backing file: base.qcow2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: base.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.8G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Scenario 7: Boot the image in snapshot chain 1, and then convert snapshot in snapshot chain 2.
1. Boot chain1_sn2.qcow2
2. Convert snapshot
# qemu-img convert -p -f qcow2 chain1_sn1.qcow2 -O qcow2 new.qcow2
    (100.00/100%)
# qemu-img convert -p -f qcow2 base.qcow2 -O qcow2 new1.qcow2
    (100.00/100%)
# qemu-img convert -p -f qcow2 chain2_sn1.qcow2 -O qcow2 new2.qcow2
    (100.00/100%)

According to the comment 5, comment 8, comment 10 and comment 11, set the bug as verified.

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://access.redhat.com/errata/RHBA-2018:1105