From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UbXwt-0005HO-3C for qemu-devel@nongnu.org; Sun, 12 May 2013 11:12:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UbXwr-00008N-Q1 for qemu-devel@nongnu.org; Sun, 12 May 2013 11:12:31 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:36987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UbXwr-00007n-Jh for qemu-devel@nongnu.org; Sun, 12 May 2013 11:12:29 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 12 May 2013 09:12:25 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 8F6891FF001E for ; Sun, 12 May 2013 09:07:15 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4CFCLU3109748 for ; Sun, 12 May 2013 09:12:22 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4CFCL9f002873 for ; Sun, 12 May 2013 09:12:21 -0600 Message-ID: <518FB154.9080500@linux.vnet.ibm.com> Date: Sun, 12 May 2013 23:12:20 +0800 From: Dong Xu Wang MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] QEMU Guest and Host channel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: wdongxu@cn.ibm.com Hi, Now QEMU has a guest agent tool: http://wiki.qemu.org/Features/QAPI/GuestAgent Guest agent is used to send "guest agent commands" to agent, and agent will do some work and return the results via QMP protocol. Now qemu-guest-agent is mainly for single direction: Host->Guest, that is users will send command from host to guest. I think it is useful to extend single direction to two-way protocol. Because sometimes, guest OS might have interest in Host's information, such as QEMU versions, with/without hardware assist virtualization features, host OS versions, host RAM/CPU usage. Guest and host channel will add a individual command interface called "qemu-channel", (in the future, it is possible to merge it with qemu-ga). Usage can be like this: 1) install qemu-channel to guest OS. In windows, it also can be installed as a service, like qemu-ga.exe. 2) qemu-channel open a listen socket, waiting for user input. 3) interact with qemu-channel, using socat/nc to send command to qemu-channel, such as: {"execute":"get-host-ramsize"} 4) qemu-channel communicates with QEMU, via a certain transport method. QEMU returns the results to qemu-channel. 5) qemu-channel writes result to client. Since qemu guest agent already has channel/service/commands code, I think I can re-use some of them. Do you have any suggestions or requests about my RFC? Please let me know your ideas, thanks in advance. :)