On 06/03/2011 07:57 AM, Daniel P. Berrange wrote:
On Fri, Jun 03, 2011 at 07:43:24AM -0500, Anthony Liguori wrote:
On 06/03/2011 04:26 AM, Daniel P. Berrange wrote:
errors stop a guest) instead of trying to model an internal QEMU
concept (vm_stop()).
If you have other user visible concepts that you want to know about,
please share the use-cases and we can think about how to model it
such that it's not exposing internal QEMU details.
None of the requested info is exposing internal QEMU impl details
with one exception. The reasons are either administrative commands,
host OS failures, guest OS failures, or the exception, KVM internal
emulation failure.
The core problem is that an app connects to QEMU, finds it is paused,
and wants to decide what action to take. If the guest is paused due
to a previous admin 'stop' command,
Let's be very clear here. QEMU does not provide a way to figure out
what the previous QMP user did. That is not a use case we support
today and it's not one we can support by just adding a reason to
stop. It's far more complicated than just that.
it will allow resuming. If it is
paused due to guest OS poweroff,
This is legitimate but only occurs if you use -no-shutdown. So
having a query-state have a "powered-off" flag would be a Good
Thing.
it might decide to issue a 'system_reset'
command and then 'resume'. If it is paused due to watchdog,
I think what we're getting at is the need for an enumeration. So
let's introduce one. Here's what I propose:
SQMP
query-status
------------
Return a json-object with the following information:
- "running": true if the VM is running, or false if it is paused (json-bool)
- "singlestep": true if the VM is in single step mode,
false otherwise (json-bool)
- "status": one of the following values (json-string) (optional)
"prelaunch" - QEMU was started with -S and guest has not started
"running" - guest is actively running
"singlestep" - guest is running in single step mode
"paused" - guest has been paused via the 'stop' command
"postmigrate" - guest is paused following a successful 'migrate'
"shutdown" - guest is shut down (and -no-shutdown is in use)
"io-error" - the last IOP has failed and the device is
configured to pause on I/O errors
"watchdog-error" - the watchdog action is configured to pause
and has been triggered