Bug 1595180 - Can't set rerror/werror with usb-storage
Summary: Can't set rerror/werror with usb-storage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Qianqian Zhu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-26 10:02 UTC by Kevin Wolf
Modified: 2018-11-01 11:12 UTC (History)
9 users (show)

Fixed In Version: qemu-kvm-rhev-2.12.0-7.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-01 11:10:36 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3443 None None None 2018-11-01 11:12:30 UTC

Description Kevin Wolf 2018-06-26 10:02:20 UTC
Most block devices that can support different error handling policies make those available as -device options, so that the policy can be selected even when using -blockdev for the backend. However, the error policy for usb-storage can still only be configured with -drive and not with a qdev property.

This is blocking -blockdev support in libvirt.

Comment 2 Miroslav Rezanina 2018-07-04 08:42:27 UTC
Fix included in qemu-kvm-rhev-2.12.0-7.el7

Comment 4 Qianqian Zhu 2018-07-09 09:32:10 UTC
Test on qemu-kvm-rhev-2.12.0-7.el7.x86_64:

Steps:
1. Launch guest with usb-storage, specifying rerror=stop and werror=stop:
# /usr/libexec/qemu-kvm \
-enable-kvm \
-m 2G \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4   \
-blockdev node-name=driver0,driver=file,filename=/home/rhel76-64-virtio-scsi.qcow2 \
-blockdev driver=qcow2,node-name=drive0-debug,file.driver=blkdebug,file.image=driver0,file.config=blkdebug.conf \
-device usb-storage,id=image1,drive=drive0-debug,share-rw=on,rerror=stop,werror=stop \
-device virtio-net-pci,mac=9a:f8:f9:fa:fb:fc,id=idWyOFPn,vectors=4,netdev=idC4NXQZ,bus=pci.0,addr=0x5   \
-netdev tap,id=idC4NXQZ,vhost=on  \
-vnc :1 \
-msg timestamp=on  \
-usb \
-qmp stdio

2. Trigger I/O error.

Scenario 1:
# cat blkdebug.conf 
[inject-error]
event = "l2_load"

Result:
{ "execute": "human-monitor-command","arguments": {"command-line": 'qemu-io drive0-debug "read 0 512"' }}
read failed: Input/output error
{"return": ""}
{"execute":"query-status"}
{"return": {"status": "io-error", "singlestep": false, "running": false}}
{ "execute": "human-monitor-command","arguments": {"command-line": 'qemu-io drive0-debug "write 0 512"' }}
write failed: Input/output error
{"return": ""}
{"execute":"query-status"}
{"return": {"status": "io-error", "singlestep": false, "running": false}}

Scenario 2:
# cat blkdebug.conf 
[inject-error]
event = "write_aio"

Result:
{ "execute": "human-monitor-command","arguments": {"command-line": 'qemu-io drive0-debug "read 0 512"' }}
read 512/512 bytes at offset 0
512 bytes, 1 ops; 0.0000 sec (12.850 MiB/sec and 26315.7895 ops/sec)
{"return": ""}
{"execute":"query-status"}
{"return": {"status": "running", "singlestep": false, "running": true}}
{ "execute": "human-monitor-command","arguments": {"command-line": 'qemu-io drive0-debug "write 0 512"' }}
write failed: Input/output error
{"return": ""}
{"timestamp": {"seconds": 1531127916, "microseconds": 214359}, "event": "BLOCK_IO_ERROR", "data": {"device": "", "nospace": false, "__com.redhat_reason": "eio", "node-name": "drive0-debug", "reason": "Input/output error", "operation": "read", "action": "stop"}}
{"timestamp": {"seconds": 1531127916, "microseconds": 214442}, "event": "STOP"}

In both scenarios qemu do stop the guest after I/O error being triggered.
So moving to VERIFIED.

Comment 5 errata-xmlrpc 2018-11-01 11:10:36 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/RHBA-2018:3443


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