Quick question on the reproducer: does step 3's dd complete before you
unplug (step 4)?

On actual and expected results: please provide output of dd in the
guest, and the relevant tail of the guest's dmesg.

(In reply to Markus Armbruster from comment #3)
> Quick question on the reproducer: does step 3's dd complete before you
> unplug (step 4)?
> 

no, the test point is to see if the VM stops(and it did), and raise error about the storage


> On actual and expected results: please provide output of dd in the
> guest, and the relevant tail of the guest's dmesg.

no output, the VM has already paused.

I'm confused.  Under "Actual results" you wrote the guest isn't paused, but now you tell me it is.  Please advise.

My attempts to reproduce this failed.  When I unplug my memory stick, the guest is paused due to I/O error as expected.

(In reply to Markus Armbruster from comment #5)
> I'm confused.  Under "Actual results" you wrote the guest isn't paused, but
> now you tell me it is.  Please advise.

my fault, I was wanna to tell the guest was running w/p problem before I unplug the usb storage, so I included both running, and pause status , now I seperate them as below
------------------------------------- guest running well, usb storage plugged as /dev/sdb on host

VM status: running
(qemu) info block
drive_image1: /home/w39.qcow2 (qcow2)
    Cache mode:       writeback, direct
    Backing file:     /home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-7.2-64-virtio-scsi.qcow2 (chain depth: 1)

drive_image2: /dev/sdb (raw)
    Cache mode:       writeback, direct



====================================== guest paused, nothing output from qemu monitor


(qemu) info status 
VM status: paused (io-error)
(qemu) info block
drive_image1: /home/w39.qcow2 (qcow2)
    Cache mode:       writeback, direct
    Backing file:     /home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-7.2-64-virtio-scsi.qcow2 (chain depth: 1)

drive_image2: /dev/sdb (raw)
    I/O status:       failed
    Cache mode:       writeback, direct
(qemu) q

All right, let's pick apart actual and expected results.

We have:

1. VM status, as reported by "info status"

2. I/O status of block backend drive_image2, as reported by "info block"

3. QMP event BLOCK_IO_ERROR

4. Additional messages to the (HMP) monitor and/or stderr

Actual results, please correct misunderstandings:

1. VM status: paused (io-error)

2. I/O status:       failed

3. QMP event {"timestamp": {"seconds": 1443172550, "microseconds": 199442}, "event": "BLOCK_IO_ERROR", "data": {"device": "drive_image2", "nospace": false, "reason": "Input/output error", "operation": "write", "action": "stop"}}

4. Nothing

Expected results, please correct misunderstandings:

1. Like actual result

2. Like actual result

3. Actual result plus "__com.redhat_debug_info": {"message": "Input/output error", "errno": 5} in the value of "data"

4. A bunch of "block I/O error in device 'drive_image2': Input/output error (5)"

Is this correct?

Anything missing?

(In reply to Markus Armbruster from comment #8)
(bunch of <snips>)
> We have:
> 
> 3. QMP event BLOCK_IO_ERROR
> 
> Actual results:
> 
> 3. QMP event {"timestamp": {"seconds": 1443172550, "microseconds": 199442},
> "event": "BLOCK_IO_ERROR", "data": {"device": "drive_image2", "nospace":
> false, "reason": "Input/output error", "operation": "write", "action":
> "stop"}}
> 
> Expected results, please correct misunderstandings:
> 
> 3. Actual result plus "__com.redhat_debug_info": {"message": "Input/output
> error", "errno": 5} in the value of "data"
> 

That's my understading as well. And the lack of the error code in the QMP message is the actual regression that affects libvirt (or its users).

Both QMP key "__com.redhat_debug_info" (item 3) and the "block I/O
error in device" messages (item 4) are RHEL-only extensions.

These originally come from RHEL-6 commit 1a2b98f:

    Based on a suggestion from Kevin Wolf, this commit adds a new
    json-object member to the event, containing the errno value and an
    error string from strerror(). Additionally, an error message is
    printed to stderr.
    
    All this new information is meant for human debugging only and should
    not be used by libvirt (as stated in the event's documentation entry).

They extend the prior RHEL extension QMP key "__com.redhat_reason"
from commit a635efd.

We forward-ported them both to RHEL-7 qemu-kvm, in commit 771a3a3 and
commit bfea65d.

Upstream finally added QMP key "reason" in commit 624ff57, v2.2.
qemu-kvm-rhev got it via rebase, obviating our "__com.redhat_reason".
We want to keep "__com.redhat_reason" around for now anyway, to avoid
undue conflicts with libvirt versions that still use it.  We therefore
forward-ported it in commit 44f3e45.

We decided not to forward the other commit, because we feel the
debugging aids it provides are no longer necessary:

* "__com.reason.debug_info" provides two values "message" and "errno".
  The former is identical to "reason".  The latter can be trivially
  derived from "reason".

* Spewing messages to stderr has always been a poor substitute for
  proper logging.  Libvirt's logging should be good enough now.

See the review thread
http://post-office.corp.redhat.com/archives/rhvirt-patches/2015-May/msg00008.html

I'm therefore closing this NOTABUG.  If you think we need to
forward-port these debugging aids, please reopen the bug and explain
why they are still needed.