[libvirt-users] Lifecycle of a connection to libvirtd

Hey! I am trying to figure out how to reliably maintain a connection to libvirtd. From the documentation, I would expect something like that: - virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive() - Application logic And in the registered callback, I would: - virConnectUnregisterCloseCallback() - virConnectClose() - virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive() However, looking at the source code of virsh, I see that it additional stuff, notably: - virConnectIsAlive() - checking error codes of all calls to check if they are the result of a disconnect Are those steps needed? Randomly checking virConnectIsAlive() doesn't seem reliable. Checking individual error codes either (maybe I will miss one of them or misinterpret another one). virsh code uses those error codes to check if there is a disconnection: (((last_error->code == VIR_ERR_SYSTEM_ERROR) && (last_error->domain == VIR_FROM_REMOTE)) || (last_error->code == VIR_ERR_RPC) || (last_error->code == VIR_ERR_NO_CONNECT) || (last_error->code == VIR_ERR_INVALID_CONN)))) Any hint? -- Program defensively. - The Elements of Programming Style (Kernighan & Plauger)

On Sun, Jul 24, 2016 at 11:13:08PM +0200, Vincent Bernat wrote:
Hey!
I am trying to figure out how to reliably maintain a connection to libvirtd. From the documentation, I would expect something like that:
- virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive() - Application logic
And in the registered callback, I would:
- virConnectUnregisterCloseCallback() - virConnectClose() - virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive()
However, looking at the source code of virsh, I see that it additional stuff, notably:
- virConnectIsAlive() - checking error codes of all calls to check if they are the result of a disconnect
Are those steps needed? Randomly checking virConnectIsAlive() doesn't seem reliable. Checking individual error codes either (maybe I will miss one of them or misinterpret another one).
virsh code uses those error codes to check if there is a disconnection:
(((last_error->code == VIR_ERR_SYSTEM_ERROR) && (last_error->domain == VIR_FROM_REMOTE)) || (last_error->code == VIR_ERR_RPC) || (last_error->code == VIR_ERR_NO_CONNECT) || (last_error->code == VIR_ERR_INVALID_CONN))))
Any hint?
You don't need to do any of these. The connection is checked as a part of connection callback which we have just to de-duplicate some code in virsh and virt-manager. It can happen that it is checked before the first command and needs to be connected (or reconnected) before the next one. It's mostly because we allow users to do arbitrary commands that can change where we are connected and few other things. The errors are checked because there wasn't a close callback back then and it just stuck with us. Someone should remove it and at the same time make sure one more time close callback handles these.
-- Program defensively. - The Elements of Programming Style (Kernighan & Plauger)
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users

❦ 25 juillet 2016 06:44 CEST, Martin Kletzander <mkletzan@redhat.com> :
You don't need to do any of these. The connection is checked as a part of connection callback which we have just to de-duplicate some code in virsh and virt-manager. It can happen that it is checked before the first command and needs to be connected (or reconnected) before the next one. It's mostly because we allow users to do arbitrary commands that can change where we are connected and few other things.
The errors are checked because there wasn't a close callback back then and it just stuck with us. Someone should remove it and at the same time make sure one more time close callback handles these.
Thanks for the answer! I can make a patch to remove those checks but my tests would limited to restart libvirtd while virsh is connected. I don't know if it's enough. -- Make the coupling between modules visible. - The Elements of Programming Style (Kernighan & Plauger)

❦ 24 juillet 2016 23:13 CEST, Vincent Bernat <bernat@luffy.cx> :
I am trying to figure out how to reliably maintain a connection to libvirtd. From the documentation, I would expect something like that:
- virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive() - Application logic
And in the registered callback, I would:
- virConnectUnregisterCloseCallback() - virConnectClose() - virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive()
Well, I am now doing that and it doesn't work as expected. If the connection is unexpectedly disconnected, I get an error when calling virConnectUnregisterclosecallback(): [Code-55] [Domain-20] Requested operation is not valid: A different callback was requested If I don't unregister the callback, virConnectClose() indicates a leak. The same happens for domain events. If the connection is closed unexpectedly, I get: [Code-1] [Domain-7] internal error: client socket is closed I am not even sure that I don't get a leak whatever I do about since I don't see anything that would unset the callbacks when the connection is closed (while this happens for close callback). I see that virsh has the same problem. If I restart libvirt while connected, I get a "One or more references were leaked after disconnect from the hypervisor". -- Tempt not a desperate man. -- William Shakespeare, "Romeo and Juliet"
participants (2)
-
Martin Kletzander
-
Vincent Bernat