Bug 1067414

Summary:	QEMU: report I/O error reason
Product:	[Community] Virtualization Tools	Reporter:	Francesco Romani <fromani>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	crobinso, fromani, michal.skrivanek, pmukhedk, rbalakri
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-10 17:49:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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