qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Using QEMU guest agent to run programs from guest path]


From: mdroth
Subject: Re: [Qemu-devel] Using QEMU guest agent to run programs from guest path]
Date: Thu, 3 Jan 2013 13:09:13 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jan 03, 2013 at 11:06:02AM -0200, Erlon Cruz wrote:
> On Wed, Jan 2, 2013 at 9:04 PM, mdroth <address@hidden> wrote:
> 
> > On Mon, Dec 31, 2012 at 06:14:59PM -0200, Erlon Cruz wrote:
> > > Hi,
> > >
> > >
> > > I needed to run an external program in a guest machine. Once this must be
> > > triggered by the host, I first thought in qemu-ga.
> > > Is that possible? In QEMU help page and in the code I couldn't find such
> > > capability.
> > > So Im thinking In to implement a new GA QMP command that can run generic
> > > programs in the guest. It would be receive/return something like this:
> > >
> > > {"execute":"execvp",
> > > "arguments":{"command":"/bin/ls","cmdargs":"-la","timeout":20}}
> > > {"return": {"status": "0", "stdout": "aGVsbG8gd29ybGQhCg==", "stderr":
> > ""}}
> > >
> > > Any thoughts/ideas about this?
> >
> > I sent an RFC for this a while back:
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00722.html
> >
> > At the time the interface seemed a bit tedious, but AFAIK it's the only
> > kind of approach that'll work for longer-running commands with lots of
> > output, so I might just clean it up and re-spin the series.
> >
> >
> Why you say tedious? The interface seems to have a very wide usage for

The parameter passing for guest commands was kludgy (list of json
objects rather than a list of parameter strings), but I think we can handle
that now with the "gen: no" option to the code parser indicating we'll
handle it manually.

I'm not sure about the guest-file-open-pipe stuff either. It seems
clumsy, but I can't think of a better approach.

I'll look at it and shoot to get in by 1.4, but feature freeze is only a
couple weeks away so it may have to wait till 1.5.

> several scenarios and fits perfectly for what we are trying to do. Why it
> didn't go upstream? I think it would be nice to roll that up again.
> 
> Erlon
> 
> >
> > > Kind Regards,
> > > Erlon
> >



reply via email to

[Prev in Thread] Current Thread [Next in Thread]