From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJtOL-00077M-BH for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:09:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJtOG-00077A-Jf for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:09:44 -0400 Received: from [199.232.76.173] (port=36327 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJtOG-000777-Gw for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:09:40 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:41222) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJtOG-0001Qf-5m for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:09:40 -0400 Received: by ewy7 with SMTP id 7so2320457ewy.34 for ; Thu, 25 Jun 2009 11:09:39 -0700 (PDT) Message-ID: <4A43BD5D.80307@codemonkey.ws> Date: Thu, 25 Jun 2009 13:09:33 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> <4A4252DD.70300@redhat.com> <20090624190539.GR14121@shareable.org> <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> In-Reply-To: <4A4395B8.4010401@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez Avi Kivity wrote: >> An RPC is overkill unless you also introduce things like life cycle >> management. Otherwise, you could never realistically interact with >> QEMU without a intermediary that handled life cycle management (e.g. >> libvirt). > > QMP is an RPC implemented over a text based protocol, with ad-hoc > marshalling. > > I agree that you need something to reap dead qemus, but I don't think > we can force libvirt on people. QMP is an incremental improvement to the current monitor which people are consuming today. It will have a pretty immediate and high rate of return. libvirt can make use of it with probably very little change and it will immediately provide them with new features (async notifications) and better information about commands (error return values). I have a really hard time not thinking this is the right thing to do because for relatively little churn we'll get a large return. If you just exposed the monitor as an RPC, I don't think you really get anything more useful than QMP and you force a lot more change in libvirt which hurt the adoption of this protocol. This is exactly what happened with Xend's transition from SExpr/HTTP (custom RPC) -> XML-RPC -> XenAPI. libvirt still uses SExpr/HTTP because the cost of switching to the new way of doing things didn't warrant the return on investment. s/libvirt/any other management tool that works today/g Regards, Anthony Liguori