Hide Forgot
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.
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.