Bug 1525324

Summary: 2 VMs both with 'share-rw=on' appending on '-device usb-storage' for the same source image can not be started at the same time
Product: Red Hat Enterprise Linux 7 Reporter: jiyan <jiyan>
Component: qemu-kvm-rhevAssignee: Fam Zheng <famz>
Status: CLOSED ERRATA QA Contact: Gu Nini <ngu>
Severity: high Docs Contact:
Priority: high    
Version: 7.5CC: chayang, cliao, dyuan, hhan, jiyan, juzhang, knoel, lmen, lmiksik, meili, michen, ngu, pkrempa, qzhang, virt-maint, xuma, xuzhang, yisun
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: qemu-kvm-rhev-2.10.0-19.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-11 00:52:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1525303    

Description jiyan 2017-12-13 03:50:33 UTC
Description of problem:
2 VMs both with <shareable/> configured for same source image in usb bus can not start at the same time

Version-Release number of selected component (if applicable):
libvirt-3.9.0-6.el7.x86_64
kernel-3.10.0-820.el7.x86_64
qemu-kvm-rhev-2.10.0-12.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Prepare 2 shutdown VM with the following configuration
# virsh domstate test1
shut off

# virsh domstate test2
shut off

# virsh dumpxml test1 --inactive|grep "<disk" -A6
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.img'/>
      <target dev='hda' bus='usb'/>
      <shareable/>
      <address type='usb' bus='0' port='3'/>
    </disk>

# virsh dumpxml test2 --inactive|grep "<disk" -A6
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.img'/>
      <target dev='hda' bus='usb'/>
      <shareable/>
      <address type='usb' bus='0' port='3'/>
    </disk>

2. Try to start 2 VMs
# virsh start test1
Domain test1 started

# ps -ef |grep test1 |sed 's/-device/\n-device/g'
qemu      4943     1  1 11:47 ?        00:00:01 /usr/libexec/qemu-kvm -name guest=test1
-drive file=/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.img,format=raw,if=none,id=drive-usb-disk0,cache=none 
-device usb-storage,bus=usb.0,port=3,share-rw=on,drive=drive-usb-disk0,id=usb-disk0,bootindex=1,removable=off -netdev tap,fd=27,id=hostnet0

# virsh start test2
error: Failed to start domain test2
error: internal error: qemu unexpectedly closed the monitor: profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-virbuffer.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-virbitmap.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-virauthconfig.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-virauth.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-viraudit.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-virarch.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-3.9.0/src/util/.libs/libvirt_util_la-viralloc.gcda:Cannot open
2017-12-13T03:14:35.670317Z qemu-kvm: -device usb-storage,bus=usb.0,port=3,share-rw=on,drive=drive-usb-disk0,id=usb-disk0,bootindex=1,removable=off: Failed to get shared "write" lock
Is another process using the image?

Actual results:
2 VMs both with <shareable/> configured for same source image in usb bus can not start at the same time, and while 'share-rw=on' already shows in the error info

Expected results:
2 VMs both with <shareable/> configured for same source image in usb bus can start at the same time

Additional info:
Under same condition with above, 2 VMs both with IDE bus or SCSI bus can work well.

Comment 3 Fam Zheng 2017-12-18 13:58:38 UTC
There is a QEMU bug that doesn't handle the "share-rw=on" from the command line correctly. I'll send a patch to upstream.

Comment 5 Gu Nini 2017-12-19 10:05:04 UTC
Failed to boot up 2 guests with 'share-rw=on' appeding on virtio scsi/block disks, so the bug is not must usb-storage related.

# /usr/libexec/qemu-kvm -name 'avocado-vt-vm1' -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0 -drive id=drive_image2,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/win10-32-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image2,bootindex=1,share-rw=on -vnc :20 -monitor stdio -cpu 'SandyBridge',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time
qemu-kvm: -drive id=drive_image2,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/win10-32-virtio-scsi.qcow2: Failed to get "write" lock
Is another process using the image?

# /usr/libexec/qemu-kvm -name 'avocado-vt-vm1' -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/win10-32-virtio-scsi.qcow2  -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,share-rw=on -vnc :20 -monitor stdio -cpu 'SandyBridge',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time
qemu-kvm: -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/win10-32-virtio-scsi.qcow2: Failed to get "write" lock
Is another process using the image?

Comment 10 Miroslav Rezanina 2018-02-02 12:40:12 UTC
Fix included in qemu-kvm-rhev-2.10.0-19.el7

Comment 12 Gu Nini 2018-02-08 08:34:04 UTC
Verify the bug on following sw versions:

Host kernel: 3.10.0-843.el7.x86_64
Qemu-kvm-rhev: qemu-kvm-rhev-2.10.0-19.el7.x86_64


2 guests could boot up with the same raw disk image as usb storage disk with 'share-rw=on appended:

-drive id=drive_image2,if=none,snapshot=off,aio=threads,cache=none,format=raw,file=/home/hd1.raw -device usb-storage,id=image2,drive=drive_image2,share-rw=on,bootindex=2,bus=usbtest.0 \

Comment 14 errata-xmlrpc 2018-04-11 00:52:14 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-2018:1104