Bug 626788 - QEMU driver needs to timeout stuck monitor commands
Summary: QEMU driver needs to timeout stuck monitor commands
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-24 12:32 UTC by Daniel Berrange
Modified: 2016-03-21 00:26 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-03-21 00:26:42 UTC


Attachments (Terms of Use)

Description Daniel Berrange 2010-08-24 12:32:05 UTC
Description of problem:
Currently when the QEMU driver issues a monitor command, it will wait forever for a reply to arrive. Any further API calls which may change the VM state are blocked during this time and will time out after failing to obtain the state change lock. libvirt should be able to timeout the original command and in some cases carry on, normally.

If the command was a 'query-xxx' info retrieval, we should be able to wait for the eventual reply in the background & discard it, in order to recover. Then we can allow further monitor commands in the future.

If the command was a state change command (eg hotplug), the catch all scenario should be to disallow all further use of the monitor, since QEMU state is now inconsistent with libvirt's XML config. We might be able to write fixup handlers on the case by case basis for specific commands.

libvirt must also allow the 'destroy' command to be run at any time.


Version-Release number of selected component (if applicable):
0.8.3

How reproducible:
Sometimes.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Cole Robinson 2016-03-21 00:26:42 UTC
Pretty sure we've had monitor job timeout for a long while


Note You need to log in before you can comment on or make changes to this bug.