From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44510 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQnN1-0002Tp-7L for qemu-devel@nongnu.org; Thu, 09 Dec 2010 15:45:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQnMl-0004zO-2Q for qemu-devel@nongnu.org; Thu, 09 Dec 2010 15:45:42 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:33456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQnMl-0004wQ-01 for qemu-devel@nongnu.org; Thu, 09 Dec 2010 15:45:27 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB9KMdr7014297 for ; Thu, 9 Dec 2010 15:22:42 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 0F7CB4DE8042 for ; Thu, 9 Dec 2010 15:43:25 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB9KjJ3t136538 for ; Thu, 9 Dec 2010 15:45:19 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB9KjJW3012810 for ; Thu, 9 Dec 2010 15:45:19 -0500 Message-ID: <4D013FDD.4090708@linux.vnet.ibm.com> Date: Thu, 09 Dec 2010 14:45:17 -0600 From: Michael Roth MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, Jes.Sorensen@redhat.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, abeekhof@redhat.com On 12/08/2010 04:10 AM, Stefan Hajnoczi wrote: > On Fri, Dec 3, 2010 at 6:03 PM, Michael Roth wrote: >> These patches apply to master, and can also be obtained from: >> git://repo.or.cz/qemu/mdroth.git virtagent_v5 > > Why XML-RPC and not QMP? When I skim through the patch series it > seems like much of the work being done is very similar to QMP. > It does, actually, more than I realized. In terms of data encapsulation I don't see why we couldn't use QMP/JSON for at least the current set of RPCs. XMLRPC does support a wider range of data types however, such as nestable arrays and structs, and set-precision numerical types like 32 and 64-bit ints/floats, which may prove useful for future lower level interfaces. QMP can be fairly trivially extended for some of these things, but JSON is a limiting factor in some cases. We can't maintain strong typing of data across the transport for instance, since JSON only allows for a generic number type, whereas with XMLRPC we can explicitly specify the machine representation. But whether this really matters is hard to say with the limited set of RPCs we have right now. In terms of using QMP all the way through...that sounds really cool, but with the bi-directional client/server data being multiplexed over a single channel, and increased potential for weird states resulting from guest/guest agent restarts, there's a need for some additional synchronization that might end up being fairly intrusive/undesirable to work into QMP. > What concrete use-cases are there? > * Reboot support on x86. A QMP command can invoke guest-initiated > reboot via virtagent. > * ? > * viewfile The ability to do a quick peek at guest stats via, say, /proc, is a use case that seems to be fairly generally desirable. It's what essentially started all this work, actually. That's also why I think a simple/limited viewfile RPC for relatively small text files is warranted regardless of whatever approach we end up taking for handling large/binary file transfers. * getdmesg Really useful for trouble-shooting things like soft-lockups. * ping Heartbeat monitoring has also been a fairly re-occurring approach to identifying potential problems in our cloud, and it's not even something we're capable of accomplishing in a production environment due to having limited network access to the guests. Being able to do it without relying on custom/network-based daemons would be pretty useful. * exec (planned) Internally and externally I've seen interest in guest-initiated snapshots, but that would tie into exec or some other, higher-level, RPC, which isn't yet well-defined. * copyfile (planned) Nothing solid, but I think it's generally desirable. Quick access to coredumps and such would be useful. Lots of discussion on how to implement this and I think we have some good potential approaches to adding this soon. * writefile (planned) Nothing solid. But guest activation is probably a big potential use case for this one. Managing various guest kernel params is another. Another would be deploying custom scripts to run via exec. > Will virtagent be extensible by host administrators or end-users? For > example, can I drop in a custom command to collect statistics and > invoke it across VMs on my hosts? Do I need to recompile QEMU and/or > the virtagent daemon? writefile + exec would probably be the best way to achieve this. I don't think there are any plans to make the supported set of RPCs pluggable/extendable. > > Stefan