Bug 1525324 - 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
Summary: 2 VMs both with 'share-rw=on' appending on '-device usb-storage' for the same...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.5
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Fam Zheng
QA Contact: Gu Nini
URL:
Whiteboard:
Keywords: Regression
Depends On:
Blocks: 1525303
TreeView+ depends on / blocked
 
Reported: 2017-12-13 03:50 UTC by jiyan
Modified: 2018-04-11 00:54 UTC (History)
18 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-11 00:52:14 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1104 None None None 2018-04-11 00:54 UTC

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


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