From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSUwF-0004YW-8G for qemu-devel@nongnu.org; Fri, 03 Jun 2011 10:01:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSUw9-0002Ng-HZ for qemu-devel@nongnu.org; Fri, 03 Jun 2011 10:01:22 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:39477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSUw9-0002Lw-4R for qemu-devel@nongnu.org; Fri, 03 Jun 2011 10:01:17 -0400 Received: by ywl41 with SMTP id 41so903299ywl.4 for ; Fri, 03 Jun 2011 07:01:16 -0700 (PDT) Message-ID: <4DE8E929.2090709@codemonkey.ws> Date: Fri, 03 Jun 2011 09:01:13 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DE6B087.6010708@codemonkey.ws> <20110602090632.GB14571@redhat.com> <4DE78B53.1010201@codemonkey.ws> <20110602132405.GJ514380@orkuz.home> <4DE797F6.2060004@codemonkey.ws> <20110602150124.0b3c187f@doriath> <20110603092602.GA32642@redhat.com> <4DE8D6EC.1010307@codemonkey.ws> <20110603125751.GD32642@redhat.com> <4DE8E120.9020904@codemonkey.ws> <20110603133941.GO32642@redhat.com> <20110603104401.15372e3e@doriath> In-Reply-To: <20110603104401.15372e3e@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , Jiri Denemark On 06/03/2011 08:44 AM, Luiz Capitulino wrote: > On Fri, 3 Jun 2011 14:39:41 +0100 > "Daniel P. Berrange" 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 > >