Bug 1067414 - QEMU: report I/O error reason
Summary: QEMU: report I/O error reason
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-20 12:30 UTC by Francesco Romani
Modified: 2019-06-13 07:57 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-04-10 17:49:51 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1284090 0 None None None Never

Description Francesco Romani 2014-02-20 12:30:53 UTC
Description of problem:
the virConnectDomainEventIOErrorReasonCallback API let the client listen for I/O error reasons; the 'reason' value is never populated.
Use case: When using the QEMU hypervisor and the disk error policy 'enospc', we need a way to distinguish the actual reason of an I/O error. The 'reason' field is supposed to be such a way.


Version-Release number of selected component (if applicable):
1.2.1.


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
the 'reason' value is empty


Expected results:
'reason' value populated


Additional info:
Code is explicitely disabled in src/qemu/qemu_monitor_json.c::qemuMonitorJSONHandleIOError

Comment 1 Francesco Romani 2014-02-24 10:27:13 UTC
the virDomainGetState API is affected as well, because the I/O error reason reported is the same being populated by the disabled code.

Comment 2 Francesco Romani 2014-02-24 12:34:04 UTC
After additional investigation, it seems QEMU doesn not export this information through the QMP protocol. filed a bug against QEMU:
https://bugs.launchpad.net/qemu/+bug/1284090

Comment 4 Michal Skrivanek 2015-01-09 16:30:36 UTC
Francesco, http://www.redhat.com/archives/libvir-list/2014-October/msg00129.html is enough, right

Comment 5 Francesco Romani 2015-01-09 16:37:37 UTC
(In reply to Michal Skrivanek from comment #4)
> Francesco,
> http://www.redhat.com/archives/libvir-list/2014-October/msg00129.html is
> enough, right

Yes, it is sufficient for VDSM use case, but I need to check if
virDomainGetState - which VDSM can use in _readPauseCode is fixed as well.

If so (as I hope!) we can finally fill this gap.

Comment 6 Francesco Romani 2015-01-16 15:53:28 UTC
(In reply to Francesco Romani from comment #5)
> (In reply to Michal Skrivanek from comment #4)
> > Francesco,
> > http://www.redhat.com/archives/libvir-list/2014-October/msg00129.html is
> > enough, right
> 
> Yes, it is sufficient for VDSM use case, but I need to check if
> virDomainGetState - which VDSM can use in _readPauseCode is fixed as well.
> 
> If so (as I hope!) we can finally fill this gap.

Event notification fixed in libvirt 1.2.10. Still checking virDomainGetState

Comment 7 Francesco Romani 2015-01-16 16:19:29 UTC
(In reply to Francesco Romani from comment #6)
> (In reply to Francesco Romani from comment #5)
> > (In reply to Michal Skrivanek from comment #4)
> > > Francesco,
> > > http://www.redhat.com/archives/libvir-list/2014-October/msg00129.html is
> > > enough, right
> > 
> > Yes, it is sufficient for VDSM use case, but I need to check if
> > virDomainGetState - which VDSM can use in _readPauseCode is fixed as well.
> > 
> > If so (as I hope!) we can finally fill this gap.
> 
> Event notification fixed in libvirt 1.2.10. Still checking virDomainGetState

Covered missing part in https://bugzilla.redhat.com/show_bug.cgi?id=1183086

For events, libvirt >= 1.2.10 is good.

Comment 8 Cole Robinson 2016-04-10 17:49:51 UTC
Closing since it sounds like this is fixed


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