Bug 681911

Summary: [RFE] return VIR_ERR_INVALID_CONN whenever a broken connection is used
Product: Red Hat Enterprise Linux 6 Reporter: Dan Kenigsberg <danken>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.2CC: berrange, bsarathy, eblake, jdenemar, xen-maint
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-26 17:46:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Dan Kenigsberg 2011-03-03 15:09:20 UTC 
Description of problem:
Currently, if a client application holds virConnection objects, they cannot be used after libvirtd is restarted. If libvirt API calls are passed with such a stale virConnectionPtr, variou errors may be returned. In particular,
VIR_ERR_SYSTEM_ERROR with at least 3 different description text strings.

This make it pretty hard to tell that the client application should reconnect to the libvirt daemon.

I suggest to return a single error code (such as VIR_ERR_INVALID_CONN) on all occasions where the connection has to be re-established.
Comment 1 Daniel Berrangé 2011-03-03 15:26:02 UTC 
VIR_ERR_INVALID_CONN is specifically for case where the pointer address is not valid, but adding a new code is of course possible.

The hard bit though is that the codepaths involved are pretty long & convoluted, and much of it is shared code. So changing the error codes reported in one scenario, may negatively effect error codes in a different scenario. 

There is work upstream to re-write some of the RPC code, which could let you check using  the 'err->domain == VIR_FROM_RPC' rather than 'err->code == VIR_ERR_INVALID_CONN'.  But even check VIR_FROM_RPC and then closing + reopening would have potential for false-positives. Perhaps if we added a virConnectPing() API which was a no-op, aside from validating connectivity

eg, so if you do something like

    if err->domain == VIR_FROM_RPC
       if (!virConnectPing())
          ...re-reconnect...

FWIW, current virt-manager code does this

            except libvirt.libvirtError, e:
                if (e.get_error_domain() == libvirt.VIR_FROM_REMOTE and
                    e.get_error_code() == libvirt.VIR_ERR_SYSTEM_ERROR):
                    logging.exception("Could not refresh connection %s." % uri)
                    logging.debug("Closing connection since libvirtd "
                                  "appears to have stopped.")


In the future that will need to check VIR_FROM_RPC too.