From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfser-0002Tn-B3 for qemu-devel@nongnu.org; Wed, 08 Apr 2015 12:16:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yfseo-0005i5-3X for qemu-devel@nongnu.org; Wed, 08 Apr 2015 12:16:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfsen-0005i1-Uc for qemu-devel@nongnu.org; Wed, 08 Apr 2015 12:16:50 -0400 Message-ID: <5525546E.5020109@redhat.com> Date: Wed, 08 Apr 2015 10:16:46 -0600 From: Eric Blake MIME-Version: 1.0 References: <1746798507.1094444.1428413473548.JavaMail.open-xchange@oxbaltgw09.schlund.de> <1428414139.25243.1.camel@profitbricks.com> <668770373.39977.1428509418086.JavaMail.open-xchange@oxbaltgw07.schlund.de> In-Reply-To: <668770373.39977.1428509418086.JavaMail.open-xchange@oxbaltgw07.schlund.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Getting VM state from outside QEMU? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Erik Rull , paulo.vital@profitbricks.com Cc: "qemu-devel@nongnu.org" On 04/08/2015 10:10 AM, Erik Rull wrote: >> >> My suggestion is to create a script that sends the QMP command >> "query-status" an then parse the result. The syntax and output is: >> >> -> { "execute": "query-status" } >> <- { "return": { "running": true, "singlestep": false, "status": >> "running" } } >> > > Sounds good - I tried that - but all attempts return that the command has not > been found. I added the following command line snippet and the results are: > [...] -qmp tcp:localhost:4444,server,nowait [...] > > 172.17.48.45 ~ # telnet 127.0.0.1 4444 > {"QMP": {"version": {"qemu": {"micro": 0, "minor": 1, "major": 2}, "package": > ""}, "capabilities": []}} You HAVE to use {"execute":"qmp_capabilities"} (possibly with an "id":...) as your first command on the monitor, before you can issue any other command. I really wish we could improve the error message: > > { "execute": "query-status" } > {"error": {"class": "CommandNotFound", "desc": "The command query-status has not > been found"}} it would be a LOT nicer if we reported 'still in negotiation phase; "qmp_capabilities" expected' than a bland "CommandNotFound". Of course, patches are welcome to improve the experience there! Similarly, once you are NOT in capabilities negotiation, any subsequent use of "qmp_capabilities" fails. That's also something where the error message could be improved. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org