On 05/23/2014 05:29 AM, Martin Kletzander wrote:
On Tue, May 20, 2014 at 05:49:54PM -0600, Eric Blake wrote:
> I'm trying to debug a new virsh command, and had two terminals up, one
> running './run gdb tools/virsh' (I originally ran virsh directly, but
> re-ran under gdb to get a trace) and the other running './run gdb
> daemon/libvirtd'. Because I forgot to use the -k0 argument to disable
> keepalives, and took too long while at a breakpoint on the libvirtd
> terminal, my virsh session tried to report a keepalive failure:
>
I also have an explicit keepalive_interval=3 in my
/etc/libvirt/libvirtd.conf (rather than the default), I don't think I
have any other non-default settings in my conf files at the moment, but
wonder if the choice of server settings matters for reproducing.
I tried reproducing that and I get no hang, plus the only difference
is that without -k0 I *sometimes* get:
warning : virKeepAliveTimer:177 : Failed to send keepalive request to
client 0x55555583d630
Other than that, everythign works fine and I only see the reconnection
happen after another command is called. Are you using some kind of
special authentication?
No, I'm just running 'virsh -c qemu:///system' from a root shell. Maybe
it's the particular virsh command I was running (in my case, 'virsh
blockcommit --wait' with patches not yet upstream, but upstream would be
similar with 'virsh blockcopy --wait') - the single virsh command is
actually a while() loop of API calls to poll for status; it could be
that the reconnect works if between commands that only do one API call,
but because of this particular command calling API in a while loop, it
is not breaking out of the loop properly on a reconnect attempt.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org