Bug 1447184

Summary: qemu abort when live snapshot for multiple block device simultaneously with transaction and one is to a non-exist path
Product: Red Hat Enterprise Linux 7 Reporter: Qianqian Zhu <qizhu>
Component: qemu-kvm-rhevAssignee: Jeff Cody <jcody>
Status: CLOSED ERRATA QA Contact: Qianqian Zhu <qizhu>
Severity: high Docs Contact:
Priority: urgent    
Version: 7.4CC: chayang, juzhang, knoel, kwolf, lmiksik, michen, thuth, virt-bugs, virt-maint, xfu
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-rhev-2.9.0-10.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-02 04:38:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Qianqian Zhu 2017-05-02 04:32:47 UTC
Description of problem:
qemu abort when live snapshot for multiple block device simultaneously with transaction and one is to a non-exist path.

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


How reproducible:


Steps to Reproduce:
1. Launch guest with two block device.

# gdb /usr/libexec/qemu-kvm

(gdb)  run -drive file=/home/rhel74-64-virtio-scsi.qcow2,format=qcow2,if=none,id=drive-scsi-disk0,werror=stop,rerror=stop,cache=none -device virtio-scsi-pci,id=scsi0 -device scsi-hd,drive=drive-scsi-disk0,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk0 -monitor stdio -qmp tcp:0:5555,server,nowait -vnc :3 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=70:e2:84:14:0e:15 -drive file=/home/test.qcow2,format=qcow2,if=none,id=drive-scsi-disk1,werror=stop,rerror=stop,cache=none -device scsi-hd,drive=drive-scsi-disk1,bus=scsi0.0,scsi-id=1,lun=1,id=scsi-disk1

2. live snapshot simultaneously with transaction, "/home/test/test/test" below does not exist.
{ "execute": "transaction", "arguments": { "actions": [ { 'type': 'blockdev-snapshot-sync', 'data' : { "device": "drive-scsi-disk0","snapshot-file": "/home/sn1-a.qcow2","mode": "absolute-paths", "format": "qcow2" } }, { 'type': 'blockdev-snapshot-sync', 'data' : { "device": "drive-scsi-disk1","snapshot-file": "/home/test/test/test","mode": "absolute-paths", "format": "qcow2" } }]}}


Actual results:
qemu abort.
(qemu) [Thread 0x3fffb47eea80 (LWP 11890) exited]
Formatting '/home/sn1-a.qcow2', fmt=qcow2 size=21474836480 backing_file=/home/rhel74-64-virtio-scsi.qcow2 backing_fmt=qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
[New Thread 0x3fffb47eea80 (LWP 11968)]
Formatting '/home/test/test/test', fmt=qcow2 size=21474836480 backing_file=/home/test.qcow2 backing_fmt=qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
Unexpected error in bdrv_check_update_perm() at block.c:1611:
Conflicts with use by drive-scsi-disk0 as 'backing', which does not allow 'write' on #block198

Program received signal SIGABRT, Aborted.
0x00003fffb6f2ef90 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

Expected results:
qmp prompt error like:
{"error": {"class": "GenericError", "desc": "Could not create file: No such file or directory"}}


Additional info:
1. This issue is ppc only, x86 works well.
2. qmp prompts error as expect and qemu works normally if replace step 2 with either:
{ "execute": 'blockdev-snapshot-sync', "arguments": { "device": "drive-scsi-disk1","snapshot-file": "/home/test/test/test","mode": "absolute-paths", "format": "qcow2" } }
or:
{ "execute": "transaction", "arguments": { "actions": [ { 'type': 'blockdev-snapshot-sync', 'data' : { "device": "drive-scsi-disk1","snapshot-file": "/home/test/test/test","mode": "absolute-paths", "format": "qcow2" } }]}}

Comment 2 Qianqian Zhu 2017-05-02 04:34:33 UTC
Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.9.0-1.el7.ppc64le
kernel-3.10.0-657.el7.ppc64le

How reproducible:
100%

Comment 3 David Gibson 2017-05-02 06:59:16 UTC
Please check if the same error occurs on x86, this seems relatively unlikely to be powerpc specific.

Comment 4 Thomas Huth 2017-05-02 07:09:28 UTC
(In reply to David Gibson from comment #3)
> Please check if the same error occurs on x86, this seems relatively unlikely
> to be powerpc specific.

It's already mentioned in the description, under "Additional info" - seems like it is powerpc specific indeed.

Comment 5 Qianqian Zhu 2017-05-02 07:51:05 UTC
This works well on qemu-kvm-rhev-2.6.0-27.el7.ppc64le, so should be a regression.

Comment 7 Qianqian Zhu 2017-05-02 08:21:31 UTC
Sorry, I have tested on a wrong version for x86, this issue also exists on qemu-kvm-rhev-2.9.0-1.el7.x86_64. So it is not ppc specific.

Comment 10 Jeff Cody 2017-06-07 14:11:06 UTC
Patch sent upstream: 

https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg01773.html

Comment 11 Ademar Reis 2017-06-12 14:56:06 UTC
Patch posted to rhvirt-patches, brew build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13405619

We need qa_ack+

Comment 12 Miroslav Rezanina 2017-06-13 16:33:57 UTC
Fix included in qemu-kvm-rhev-2.9.0-10.el7

Comment 13 Qianqian Zhu 2017-06-14 07:36:20 UTC
Verified with:
qemu-kvm-rhev-2.9.0-10.el7.x86_64
kernel-3.10.0-679.el7.x86_64

Steps exactly same as comment0.
Result:
As expected, qmp prompts error and does not perform any block job:
{"error": {"class": "GenericError", "desc": "Could not create file: No such file or directory"}}

Comment 15 Chao Yang 2017-06-15 01:29:25 UTC
(In reply to Qianqian Zhu from comment #13)
> Verified with:
> qemu-kvm-rhev-2.9.0-10.el7.x86_64
> kernel-3.10.0-679.el7.x86_64
> 
> Steps exactly same as comment0.
> Result:
> As expected, qmp prompts error and does not perform any block job:
> {"error": {"class": "GenericError", "desc": "Could not create file: No such
> file or directory"}}

Setting VERIFIED.

Comment 18 errata-xmlrpc 2017-08-02 04:38:29 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://access.redhat.com/errata/RHSA-2017:2392