Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.