4:13 p.m.
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)
11:44 p.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
12:03 a.m.
❦ 25 juillet 2016 06:44 CEST, Martin Kletzander <mkletzan(a)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)
1:54 p.m.
❦ 24 juillet 2016 23:13 CEST, Vincent Bernat <bernat(a)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"
3010
days inactive
3043
days old
3 comments
2 participants
participants (2)
-
Martin Kletzander -
Vincent Bernat