From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXyBG-00056k-1w for qemu-devel@nongnu.org; Tue, 06 Dec 2011 11:47:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXyBA-000270-5W for qemu-devel@nongnu.org; Tue, 06 Dec 2011 11:47:46 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:53553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXyB9-00026q-So for qemu-devel@nongnu.org; Tue, 06 Dec 2011 11:47:40 -0500 Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 6 Dec 2011 11:47:34 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB6GiSi2089500 for ; Tue, 6 Dec 2011 11:44:29 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB6Ghgqs023649 for ; Tue, 6 Dec 2011 14:43:42 -0200 Message-ID: <4EDE463E.2000304@linux.vnet.ibm.com> Date: Tue, 06 Dec 2011 10:43:42 -0600 From: Michael Roth MIME-Version: 1.0 References: <1323182048-12134-1-git-send-email-mdroth@linux.vnet.ibm.com> <20111206144417.GA8039@redhat.com> In-Reply-To: <20111206144417.GA8039@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/2] [RFC] qemu-ga: add support for guest command execution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: bazulay@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, agl@us.ibm.com On 12/06/2011 08:44 AM, Daniel P. Berrange wrote: > On Tue, Dec 06, 2011 at 08:34:06AM -0600, Michael Roth wrote: >> The code is still in rough shape, but while we're on the topic of guest agents >> I wanted to put out a working example of how exec functionality can be added >> to qemu-ga to provide a mechansim for building arbitrarilly high-level >> interfaces. >> >> The hope is that by allowing qemu-ga to execute commands in the guest, paired >> with file read/write access, we can instrument a guest "on the fly" to support >> any type of hyperviser functionality, and do so without dramatically enlarging >> the role qemu-ga plays as a small, QEMU-specific agent that is tightly >> integrated with QEMU/QMP/libvirt. >> >> These patches add the following interfaces: >> >> guest-file-open-pipe >> guest-exec >> guest-exec-status >> >> The guest-file-open-pipe interface is analagous to the existing guest-file-open >> interface (it might be best to roll it into it actually): it returns a handle >> that can be handled via the existing guest-file-{read,write,flush,close} >> interface. Internally it creates a FIFO pair that we can use to associate >> handles to the stdin/stdout/stderr of a guest-exec spawned process. We can also >> also use them to redirect output into other processes, giving us the basic >> tools to build a basic shell (or a full-blown one if we add TTY support) using >> a single qemu-ga. >> >> Theoretically we can even deploy other agents, including session-level agents, >> and communicate with them via these same handles. Thus, ovirt could deploy and >> run an agent via qemu-ga, Spice could deploy vdagent, etc. Since the interface >> is somewhat tedious, I'm working on a wrapper script to try out some of >> these scenarios, but a basic use case using the raw QMP interface is included >> below. >> >> Any thoughts/comments on this approach are appreciated. >> >> EXAMPLE USAGE (execute `top -b -n1`): >> >> {'execute': 'guest-file-open-pipe'} >> {'return': 6} >> >> {'execute': 'guest-exec', \ >> 'arguments': {'detach': True, \ >> 'handle_stdout': 6, \ >> 'params': [{'param': '-b'}, \ >> {'param': '-n1'}], \ >> 'path': 'top'}} > > This feels like a rather verbose way of specifying > the ARGV. Why not just allow > > {'execute': 'guest-exec', \ > 'arguments': {'detach': True, \ > 'handle_stdout': 6, \ > 'params': ['-b', '-n1'], \ > 'path': 'top'}} > > Or even > > > {'execute': 'guest-exec', \ > 'arguments': {'detach': True, \ > 'handle_stdout': 6, \ > 'argv': ['top', '-b', '-n1']}} \ > Agreed, this would look way nicer and is what I was shooting for initially. Unfortunately, the QAPI-generated QMP marshalling code, and the visitor interfaces it uses, expects lists to be of structured types. We might be able to special-case it for int and char* arrays though and open-code it though... The problem I ran into when I looked at it though is that the QMP request is a QObject at that point that's contained inside a Visitor. So to manipulate it we'd have to extract the QList and manipulate it outside the visitor, which would be difficult since the Visitor is using a stack to manage it's traversal of the QObject based on the visitor calls we make, so it's difficult to pull it out of there... Although, maybe we could just add a qmp_input_vistor_stack_top() that gives us the top of the stack, then call it at the appropriate point in the marshalling code and key into it to get qobj{'argv'} and whatnot. It's kinda hacky, but it's QMP-specific, and useful, so it might be worth it. Alternatively, we could introduce another Visitor interface for handling lists of int64_t and char*. So maybe it's not so bad, I'll look into it more. > and just use the first element of argv as the binary to > execute. Also you might need to set env variables for > some tools, so we'd want > > {'execute': 'guest-exec', \ > 'arguments': {'detach': True, \ > 'handle_stdout': 6, \ > 'argv': ['top', '-b', '-n1'], \ > 'env' : ['TMPDIR=/wibble']}} > > and perhaps also you might want to run as a non-root > user, so allow a username/groupname ? > Good idea, this would open up a lot of potential use cases (X session/display management, copy/paste, etc). > Regards, > Daniel