+++ This bug was initially created as a clone of Bug #531983 +++

Re-casting to focus on the (mis) behaviour of 'virsh list'


Description of problem:

'virsh list ' will hang forever 

context and reproducer are clear from the prior bug and are not repeated here

--- Additional comment from berrange on 2009-11-11 09:24:24 EST ---

30 seconds is appropriate for this. If it were any lower then it would cause unneccessary timeouts when the host is under high load and QEMU is slow to respond.  Having a completely dead QEMU is a unusual occurrence and not something we want to optimize for. Similarly we do not want to optimize for scenario of someone deliberately sending SIGSTOP to the process.

... later

The problem was that a hang on this one guest, would also cause a hang on all other libvirt guests which are still running normally.


RPH new content: from a libvirt POV, this may be solved from in a recent release , but 'virsh list' will still hang as I understand it

> What we solved in this bug, is that you can continue to request information about *other* guests, even when this one guest has hung.

> So the first 'virsh list' you run will *still* hang.

RPH proposed:

adding the timeout and error notification to 
   virsh list
is what is proposed, not some general roll-in of a 'one size fits all' timeout

--- Additional comment from berrange on 2010-10-29 11:59:18 EDT ---

The timeout described in comment #5 is relating to timeout while waiting on a lock in another part of the code, not the timing out of currently executing monitor commands. 

Regardless, this isn't the place for design & implementation discussions.

---------------

If filing a bug against the owning component is not the right place I am misunderstanding what you are saying

The misbehavour (the hanging without timeout of 'virsh list') is what is being reported here for resolution