Bug 1415947 - data-plane cause qemu-kvm process hang when do basic Block stream for virtio-scsi
Summary: data-plane cause qemu-kvm process hang when do basic Block stream for virtio-...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev   
(Show other bugs)
Version: 7.4
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Paolo Bonzini
QA Contact: aihua liang
URL:
Whiteboard:
Keywords: Regression
Depends On:
Blocks: 1420722
TreeView+ depends on / blocked
 
Reported: 2017-01-24 07:53 UTC by Donghui Huang
Modified: 2017-08-02 03:17 UTC (History)
15 users (show)

Fixed In Version: qemu-kvm-rhev-2.9.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 23:42:15 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Description Donghui Huang 2017-01-24 07:53:31 UTC
Description of problem:
1.For virtio-scsi with data-plan. block stream will cause qemu-kvm process hang. 

2.For virtio-blk with data-plan. It works.

3.without data-plane, qemu-kvm works well.
 
4.QE tested qemu-kvm-rhev-2.6.0-27.el7.x86_64 & qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64 as well. Both work well. 

5.Currently, QE found this problem for qemu-kvm-rhev-2.8.0-2.el7.x86_64. So this is a regression bug. 

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.8.0-2.el7.x86_64
3.10.0-541.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1./usr/libexec/qemu-kvm -object iothread,id=iothread0 -drive file=/home/image/rhel7.4.qcow2,format=qcow2,if=none,id=drive-scsi-disk0,werror=stop,rerror=stop,cache=none -device virtio-scsi-pci,id=scsi0,iothread=iothread0 -device scsi-hd,drive=drive-scsi-disk0,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk0 -qmp tcp:localhost:4444,server -monitor stdio  -net tap -net nic -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,bus=virtio-serial0.0,chardev=qga0,id=qemu-ga0,name=org.qemu.guest_agent.0

2.{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-scsi-disk0","snapshot-file": "sn1", "format": "qcow2", "mode": "absolute-paths" } }
{"return": {}}

{ "execute": "block-stream", "arguments": { "device": "drive-scsi-disk0","speed":1000000000, "on-error": "report" } }
{"return": {}}

3.

Actual results:
qemu-kvm process hang.

Expected results:
works

Additional info:
rt-kernel encountered the same problem.

Comment 2 Donghui Huang 2017-01-24 08:28:43 UTC
QE tested qemu-kvm-rhev-2.6.0-29.el7.x86_64 & qemu-kvm-rhev-2.8.0-1.el7.x86_64 as well. The former works well, but the latter encounters the same problem.

Comment 4 Donghui Huang 2017-02-06 10:13:48 UTC
   QE tested qemu-kvm-rhev-2.8.0-1.el7.x86_64 , qemu-kvm-rhev-2.8.0-2.el7.x86_64 and qemu-kvm-rhev-2.8.0-3.el7.x86_64, encountering the same problem while i do block commit for virtio-scsi with data-plane. But, qemu-kvm-rhev-2.6.0-29.el7.x86_64 works well.

Comment 5 aihua liang 2017-03-09 10:12:42 UTC
Verified, the problem also exist in following version:

   kernel version: 3.10.0-566.el7.x86_64
   qemu-kvm-rhev version:qemu-kvm-rhev-2.8.0-5.el7.x86_64

Comment 6 Paolo Bonzini 2017-03-22 08:51:29 UTC
Posted patch upstream.

Comment 7 Paolo Bonzini 2017-04-20 14:55:05 UTC
Fixed by upstream commit d79df2a2ceb3cb0771146587e9a4bfb312577f46

Comment 8 aihua liang 2017-04-26 08:43:08 UTC
Verified, the problem has been resolved, so change its status to "Verified".

Test Env:
 kernel version:3.10.0-655.el7.x86_64
 qemu-kvm-rhev version:qemu-kvm-rhev-2.9.0-1.el7.x86_64
 seabios version:seabios-1.10.2-2.el7.x86_64

Test Steps:
 1.Start guest with cmds:
    /usr/libexec/qemu-kvm \
-name 'avocado-vt-vm1'  \
-sandbox off  \
-machine pc \
-nodefaults  \
-vga std  \
-chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/monitor-qmpmonitor1-20170124-161452-WcepYpO8,server,nowait \
-mon chardev=qmp_id_qmpmonitor1,mode=control  \
-chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/monitor-catch_monitor-20170124-161452-WcepYpO8,server,nowait \
-mon chardev=qmp_id_catch_monitor,mode=control \
-device pvpanic,ioport=0x505,id=idqap0h5  \
-chardev socket,id=serial_id_serial0,path=/var/tmp/serial-serial0-20170124-161452-WcepYpO8,server,nowait \
-device isa-serial,chardev=serial_id_serial0  \
-chardev socket,id=seabioslog_id_20170124-161452-WcepYpO8,path=/var/tmp/seabios-20170124-161452-WcepYpO8,server,nowait \
-device isa-debugcon,chardev=seabioslog_id_20170124-161452-WcepYpO8,iobase=0x402 \
-object iothread,id=iothread0 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=03,iothread=iothread0 \
-drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/mnt/aliang/rhel74-64-virtio.qcow2 \
-device scsi-hd,id=image1,drive=drive_image1,bus=scsi0.0,lun=0 \
-object iothread,id=iothread1 \
-device virtio-net-pci,mac=9a:b2:b3:b4:b5:b6,id=iduCv1Ln,vectors=4,netdev=idKgexFk,bus=pci.0,addr=05  \
-netdev tap,id=idKgexFk,vhost=on \
-m 4096  \
-smp 4,maxcpus=4,cores=2,threads=1,sockets=2  \
-cpu host \
-vnc :1  \
-rtc base=localtime,clock=host,driftfix=slew  \
-boot order=cdn,menu=on,strict=off \
-enable-kvm \
-monitor stdio \

  2.Do basic block stream test.
    a. {"execute":"blockdev-snapshot-sync","arguments":{"device":"drive_image1","snapshot-file":"/home/sn1","format": "qcow2", "mode": "absolute-paths"}}
    b. {"execute": "block-stream", "arguments": { "device":"drive_image1","speed":1000000000, "on-error": "report"}}
    c. {"execute": "block-job-cancel", "arguments": { "device":"drive_image1"}}

Comment 10 errata-xmlrpc 2017-08-01 23:42:15 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

Comment 11 errata-xmlrpc 2017-08-02 01:19:54 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

Comment 12 errata-xmlrpc 2017-08-02 02:11:53 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

Comment 13 errata-xmlrpc 2017-08-02 02:52:40 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

Comment 14 errata-xmlrpc 2017-08-02 03:17:22 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


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