From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43419 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQzos-0004HK-Ht for qemu-devel@nongnu.org; Fri, 10 Dec 2010 05:03:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQzor-0008V9-3w for qemu-devel@nongnu.org; Fri, 10 Dec 2010 05:03:18 -0500 Received: from mail-ww0-f53.google.com ([74.125.82.53]:62811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQzoq-0008V2-UX for qemu-devel@nongnu.org; Fri, 10 Dec 2010 05:03:17 -0500 Received: by wwi18 with SMTP id 18so3291473wwi.10 for ; Fri, 10 Dec 2010 02:03:16 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D013FDD.4090708@linux.vnet.ibm.com> References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D013FDD.4090708@linux.vnet.ibm.com> Date: Fri, 10 Dec 2010 10:03:15 +0000 Message-ID: Subject: Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth 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 Thu, Dec 9, 2010 at 8:45 PM, Michael Roth wr= ote: > On 12/08/2010 04:10 AM, Stefan Hajnoczi wrote: >> What concrete use-cases are there? >> * Reboot support on x86. =A0A 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 c= ase > that seems to be fairly generally desirable. It's what essentially starte= d > all this work, actually. That's also why I think a simple/limited viewfil= e > 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 implemen= t > this and I think we have some good potential approaches to adding this so= on. > > * 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. Perhaps "getfile" and "putfile" as names? >> Will virtagent be extensible by host administrators or end-users? =A0For >> example, can I drop in a custom command to collect statistics and >> invoke it across VMs on my hosts? =A0Do 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. Thanks for explaining this, I think this is an important aspect of virtagent. Users will want to take advantage of an always-available host<->guest management transport. There should be a clear scope defined for virtagent. For example users might include backup, monitoring, and inventory (making sure installed software is up-to-date) software. I imagine just how flexible and easy to use will be controversial because some people may feel users should use this channel into the VM carefully and only in situations where other remote access methods are not suitable (e.g. ssh, etc). If there is a flexible interface from the start then new use-cases can be implemented without modifying QEMU/virtagent source code and updating guests. Stefan