Bug 626788 - QEMU driver needs to timeout stuck monitor commands
QEMU driver needs to timeout stuck monitor commands
Status: CLOSED CURRENTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-24 08:32 EDT by Daniel Berrange
Modified: 2016-03-20 20:26 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-20 20:26:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2010-08-24 08:32:05 EDT
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-20 20:26:42 EDT
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.