libvirt users - Jul 2016 - Re: 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)