From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqXBe-0006sV-U2 for qemu-devel@nongnu.org; Wed, 23 Sep 2009 15:07:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqXBa-0006qn-G4 for qemu-devel@nongnu.org; Wed, 23 Sep 2009 15:07:34 -0400 Received: from [199.232.76.173] (port=50985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqXBa-0006qk-AW for qemu-devel@nongnu.org; Wed, 23 Sep 2009 15:07:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17031) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqXBZ-0000Vv-ON for qemu-devel@nongnu.org; Wed, 23 Sep 2009 15:07:30 -0400 Date: Wed, 23 Sep 2009 16:07:18 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree Message-ID: <20090923160718.3ea1f68e@doriath> In-Reply-To: <20090923170816.GF11759@redhat.com> References: <20090921224430.610da97b@doriath> <4AB98034.3060608@codemonkey.ws> <20090923095701.GE29269@redhat.com> <20090923170816.GF11759@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: avi@redhat.com, qemu-devel@nongnu.org On Wed, 23 Sep 2009 18:08:16 +0100 "Daniel P. Berrange" wrote: > On Wed, Sep 23, 2009 at 10:57:01AM +0100, Daniel P. Berrange wrote: > > On Tue, Sep 22, 2009 at 08:56:04PM -0500, Anthony Liguori wrote: > > > Luiz Capitulino wrote: > > > >Now the controversial part: it's json based. ;) > > > > > > > >I have chosen json because of the reasons already explained by others in > > > >the original QMP thread. Basically, json is so simple that if we design > > > >a small protocol from scratch, chances are it will look like json. > > > > > > > > > > json is not a deal break. My main concern was our ability to extend > > > json and whether supporting stock json libraries was a hard > > > requirement. I also would like to see a C client library since our > > > biggest consumer (libvirt) is based in C. > > > > I've googled around quickly and there are at least 5 pieces of C code > > and/or C libraries that can parse JSON. Hopefully one of them will be > > sufficient / suitable for libvirt's needs. We'll just need to try it > > out and see what happens.... > > I'm in the process of re-factoring the libvirt monitor handling code to > make it possible for us to add in support for QMP in parallel to the > legacy monitor support. Once the Luiz' QMP branch progresses a little > further I'll aim to make available a libvirt branch which supports QMP. Great! > To help priortization, the one critical command we need implemented > which isn't there yet is 'cont', since all our VMs are launched with > CPUs initially stopped. I will convert 'cont' as soon as the new error handling code is finished, as 'cont' can fail. > The next priorities would be 'stop', 'info cpus', 'balloon' and > 'info balloon' (all except info cpus are there in Luiz tree already > I believe). That's right. > With those we could do some useful testing & validation of the QMP work > in libvirt. Yeah, would be very nice. I was also considering writing kvm-autotest tests, will look at it. > Then in no particular order of preference the other commands we > currently make use of are > > - migrate / migrate_set_speed / info migrate > - pci_add / pci_del > - host_net_add / host_net_del / getfd / closefd > - eject / change > - usb_add / usb_del > - info block (desirable to allow query of a single device at a time) > - memsave / pmemsave > > > Figuring out how to handle password prompts for 'cont' for encrypted > qcow is probably another unusal area. Perhaps we should have explicit > commands to set the decryption passwords ahead of time, rather than > having QEMU prompt in response to 'cont' Hmm, yes, forgot about this.