qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason


From: Anthony Liguori
Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason
Date: Fri, 03 Jun 2011 09:01:13 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 06/03/2011 08:44 AM, Luiz Capitulino wrote:
On Fri, 3 Jun 2011 14:39:41 +0100
"Daniel P. Berrange"<address@hidden>  wrote:

On Fri, Jun 03, 2011 at 08:26:56AM -0500, Anthony Liguori wrote:
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

Perhaps I didn't communicate well, but this pretty much matches
what I was trying to ask for in my previous message, so gets
my vote!

Mine too, I like it. Expect patches next week :)

My only comment is that, in case this an improved version of
query-status we could have a new command (like query-statys2 or
query-vm-status).

No, let's just keep query-status and add the new field.

For compatibility, you need to fall back to using running/singlestep anyway.

Regards,

Anthony Liguori







reply via email to

[Prev in Thread] Current Thread [Next in Thread]