Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-05-03 Thread Jes Sorensen 
On 04/21/11 15:55, Michael Roth wrote:
 Did you do anything with the fsfreeze patches, or were they dropped in
 the migration to qapi?
 
 They were pending some changes required on the agent side that weren't
 really addressed/doable until this patchset, namely:
 
 1) server-side timeout mechanism to recover from RPCs that can hang
 indefinitely or take a really long time (fsfreeze, fopen, etc),
 currently it's 30 seconds, may need to bump it to 60 for fsfreeze, or
 potentially add an RPC to change the server-side timeout
 2) a simple way to temporarily turn off logging so agent doesn't
 deadlock itself
 3) a way to register a cleanup handler when a timeout occurs.
 4) disabling RPCs where proper accounting/logging is required
 (guest-open-file, guest-shutdown, etc)
 
 #4 isn't implemented...I think this could be done fairly in-evasively
 with something like:
 
 Response important_rpc():
   if (!ga_log(syslog, LEVEL_CRITICAL, important stuff happening))
 return ERROR_LOGGING_CURRENTLY_DISABLED

Either that, or maybe simply disable the full command while the freeze
is in progress? I fear we're more likely to miss a case of checking for
logging than we are to miss command disabling?

It should still be very non evasive, maybe just a flag in the struct
declaring the functions marking it as logging-required and if the
no-logging flag is set, the command is made to wait, or return -EAGAIN

 
 bool ga_log(log_domain, level, msg):
   if (log_domain == syslog)
 if (!logging_enabled  is_critical(log_level))
   return False;
 syslog(msg, ...)
   else
 if (logging_enabled)
   normallog(msg, ...)
   return True
 
 With that I think we could actually drop the fsfreeze stuff in. Thoughts?

IMHO it is better to disable the commands rather than just logging, but
either way should allow it to drop in.

Sorry for the late reply, been a bit swamped here.

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-05-03 Thread Michael Roth 

On 05/03/2011 07:51 AM, Jes Sorensen wrote:

On 04/21/11 15:55, Michael Roth wrote:

Did you do anything with the fsfreeze patches, or were they dropped in
the migration to qapi?


They were pending some changes required on the agent side that weren't
really addressed/doable until this patchset, namely:

1) server-side timeout mechanism to recover from RPCs that can hang
indefinitely or take a really long time (fsfreeze, fopen, etc),
currently it's 30 seconds, may need to bump it to 60 for fsfreeze, or
potentially add an RPC to change the server-side timeout
2) a simple way to temporarily turn off logging so agent doesn't
deadlock itself
3) a way to register a cleanup handler when a timeout occurs.
4) disabling RPCs where proper accounting/logging is required
(guest-open-file, guest-shutdown, etc)

#4 isn't implemented...I think this could be done fairly in-evasively
with something like:

Response important_rpc():
   if (!ga_log(syslog, LEVEL_CRITICAL, important stuff happening))
 return ERROR_LOGGING_CURRENTLY_DISABLED


Either that, or maybe simply disable the full command while the freeze
is in progress? I fear we're more likely to miss a case of checking for
logging than we are to miss command disabling?

It should still be very non evasive, maybe just a flag in the struct
declaring the functions marking it as logging-required and if the
no-logging flag is set, the command is made to wait, or return -EAGAIN



Yup when I actually starting dropping it in I realized this was a much 
better approach. Although, for now I just added something like if 
(!logging_enabled) { error_set(QERR_GA_LOGGING_DISABLED); return } to 
the start of functions where logging is considered critical, which will 
result in the user getting an error message about logging so it's not 
too much of a surprise to them.


The actual dispatch code closely mirrors Anthony's dispatch stuff for 
QMP so I was hesitant to try to modify it to handle this automatically, 
since it would require some changes to how the schema parsing/handling 
is done (would probably need to add a requires_logging flag in the 
schema). Wouldn't take much though. Either way, should be a clean 
conversion if we decide to go that route.




bool ga_log(log_domain, level, msg):
   if (log_domain == syslog)
 if (!logging_enabled  is_critical(log_level))
   return False;
 syslog(msg, ...)
   else
 if (logging_enabled)
   normallog(msg, ...)
   return True

With that I think we could actually drop the fsfreeze stuff in. Thoughts?


IMHO it is better to disable the commands rather than just logging, but
either way should allow it to drop in.


Kinda agree, but logging seems to be the real dependency. With the 
server-side timeouts now in place even doing stuff like fopen/fwrite is 
permitted (it would just timeout if it blocked too long). It's the 
logging stuff that we don't really have a way to recover from, because 
it's not run in a thread we can just nuke after a certain amount of time.


Even when we're not frozen, we can't guarantee an fopen/fwrite/fread 
will succeed, so failures shouldn't be too much of a surprise since they 
need to be handled anyway. And determining whether or not a command 
should be marked as executable during a freeze is somewhat nebulous 
(fopen might work for read-only access, but hang for write access when 
O_CREATE is set, fwrite might succeed if it doesn't require a flush, 
etc), plus internal things like logging need to be taken into account.


So, for now at least I think it's a reasonable way to do it.



Sorry for the late reply, been a bit swamped here.


No problem I have your patches in my tree now. They still need a little 
bit of love and testing but I should be able to get them out on the list 
shortly.




Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-05-03 Thread Jes Sorensen 
On 05/03/11 15:53, Michael Roth wrote:

 IMHO it is better to disable the commands rather than just logging, but
 either way should allow it to drop in.
 
 Kinda agree, but logging seems to be the real dependency. With the
 server-side timeouts now in place even doing stuff like fopen/fwrite is
 permitted (it would just timeout if it blocked too long). It's the
 logging stuff that we don't really have a way to recover from, because
 it's not run in a thread we can just nuke after a certain amount of time.
 
 Even when we're not frozen, we can't guarantee an fopen/fwrite/fread
 will succeed, so failures shouldn't be too much of a surprise since they
 need to be handled anyway. And determining whether or not a command
 should be marked as executable during a freeze is somewhat nebulous
 (fopen might work for read-only access, but hang for write access when
 O_CREATE is set, fwrite might succeed if it doesn't require a flush,
 etc), plus internal things like logging need to be taken into account.
 
 So, for now at least I think it's a reasonable way to do it.

Please be very careful with any fwrite() calls - it's not just logging.
Any writes to the frozen file systems will result in the caller being
put to sleep until the file system is unfrozen. It won't timeout, and
the agent will be stuck hanging in that call.

It's fun playing with the fsfreeze stuff on your desktop system - doing
it in an xterm has 'interesting' effects. :)

This is why I prefer the 'disable function' rather 'disable logging'
approach.

 Sorry for the late reply, been a bit swamped here.
 
 No problem I have your patches in my tree now. They still need a little
 bit of love and testing but I should be able to get them out on the list
 shortly.

Sounds great!

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-05-03 Thread Michael Roth 

On 05/03/2011 09:12 AM, Jes Sorensen wrote:

On 05/03/11 15:53, Michael Roth wrote:


IMHO it is better to disable the commands rather than just logging, but
either way should allow it to drop in.


Kinda agree, but logging seems to be the real dependency. With the
server-side timeouts now in place even doing stuff like fopen/fwrite is
permitted (it would just timeout if it blocked too long). It's the
logging stuff that we don't really have a way to recover from, because
it's not run in a thread we can just nuke after a certain amount of time.

Even when we're not frozen, we can't guarantee an fopen/fwrite/fread
will succeed, so failures shouldn't be too much of a surprise since they
need to be handled anyway. And determining whether or not a command
should be marked as executable during a freeze is somewhat nebulous
(fopen might work for read-only access, but hang for write access when
O_CREATE is set, fwrite might succeed if it doesn't require a flush,
etc), plus internal things like logging need to be taken into account.

So, for now at least I think it's a reasonable way to do it.


Please be very careful with any fwrite() calls - it's not just logging.
Any writes to the frozen file systems will result in the caller being
put to sleep until the file system is unfrozen. It won't timeout, and
the agent will be stuck hanging in that call.

It's fun playing with the fsfreeze stuff on your desktop system - doing
it in an xterm has 'interesting' effects. :)

This is why I prefer the 'disable function' rather 'disable logging'
approach.



I'll review the code to make sure, but what I mean is that the actual 
daemon only ever does disk i/o when it's doing logging. All the RPCs are 
handled in a separate worker thread, so if they do something fubar we 
should still be able to recover (the timeouts are done by 
pthread_cancel()'ing the worker thread). So things should be recoverable 
so long as we don't log when frozen. RPCs succeeding or failing we don't 
care too much about, since they'll just result in a nice command timed 
out response to the user eventually.


Checking logging_enabled is more to ensure we don't let the user exploit 
the fs_freeze side-effects to do sensitive stuff under the guest owner's 
nose (not that we couldn't anyway from host, but it may important for 
piece of mind about have an externally accessible/privileged agent in 
your guest).


works_under_fsfreeze is harder to determine beforehand, unless maybe you 
flag any command that did i/o other than logging...but there are 
actually use cases where that would be too restrictive. If they're using 
fwrite to pipe output through a character device, for instance, or 
twiddling knobs in sysfs. Better to keep the same semantics as you'd 
have when physically on the machine, when possible.


Will need to do some good testing though, fsfreeze is definitely a 
strange state to be in :)



Sorry for the late reply, been a bit swamped here.


No problem I have your patches in my tree now. They still need a little
bit of love and testing but I should be able to get them out on the list
shortly.


Sounds great!

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-26 Thread Jes Sorensen 
On 04/21/11 22:58, Michael Roth wrote:
 On 04/21/2011 09:10 AM, Jes Sorensen wrote:
 On 04/18/11 17:02, Michael Roth wrote:
 One thing I cannot seem to figure out with this tree - the agent
 commands do not seem to show up in the monitor? What am I missing?
 
 Hmm, for some reason this email never hit my inbox.
 
 You mean with the human monitor? Currently, with these new patches,
 we're QMP only. And most of the command names/semantics have changed as
 well. The qapi-schema.json changes in patch 16 have the new prototypes,
 and the 0 patch has some usage examples.

Hi Michael,

Yeah it was the conclusion I came to on Thursday when I was working on
porting the freeze patches over. After fighting the json %#$%#$%#$ I
ended up with something I couldn't test in the end :(

Any plans to add human monitor support in the near future?

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-26 Thread Michael Roth 

On 04/26/2011 01:57 AM, Jes Sorensen wrote:

On 04/21/11 22:58, Michael Roth wrote:

On 04/21/2011 09:10 AM, Jes Sorensen wrote:

On 04/18/11 17:02, Michael Roth wrote:
One thing I cannot seem to figure out with this tree - the agent
commands do not seem to show up in the monitor? What am I missing?


Hmm, for some reason this email never hit my inbox.

You mean with the human monitor? Currently, with these new patches,
we're QMP only. And most of the command names/semantics have changed as
well. The qapi-schema.json changes in patch 16 have the new prototypes,
and the 0 patch has some usage examples.


Hi Michael,

Yeah it was the conclusion I came to on Thursday when I was working on
porting the freeze patches over. After fighting the json %#$%#$%#$ I
ended up with something I couldn't test in the end :(


I actually worked on getting most of the fsfreeze ported over yesterday, 
were they any major changes from the last set of patches other than the 
porting work? If so, feel free to send the patches my way and I'll hack 
on those a bit, otherwise I plan to have the fsfreeze stuff included in 
the next re-spin later this week.




Any plans to add human monitor support in the near future?


The main target will be QMP for the initial patches. But ideally the HMP 
commands we add will have a pretty close correspondence with QMP.




Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-26 Thread Jes Sorensen 
On 04/26/11 16:27, Michael Roth wrote:
 On 04/26/2011 01:57 AM, Jes Sorensen wrote:
 Yeah it was the conclusion I came to on Thursday when I was working on
 porting the freeze patches over. After fighting the json %#$%#$%#$ I
 ended up with something I couldn't test in the end :(
 
 I actually worked on getting most of the fsfreeze ported over yesterday,
 were they any major changes from the last set of patches other than the
 porting work? If so, feel free to send the patches my way and I'll hack
 on those a bit, otherwise I plan to have the fsfreeze stuff included in
 the next re-spin later this week.

I'll try and post them later today.

 Any plans to add human monitor support in the near future?
 
 The main target will be QMP for the initial patches. But ideally the HMP
 commands we add will have a pretty close correspondence with QMP.

That is unfortunate, QMP is really user unfriendly :(

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-21 Thread Jes Sorensen 
On 04/18/11 17:02, Michael Roth wrote:
 These apply on top of Anthony's glib tree, commit 
 03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained 
 from:
 git://repo.or.cz/qemu/mdroth.git qga_v2
 
 Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider 
 pulling these into your glib tree. The json fix-ups may need further 
 evaluation, but I'm confident they're at least an improvement. The QAPI ones 
 are mostly trivial fix-ups.
 
 Changes since V1:
 
 - Added guest agent worker thread to execute RPCs in the guest. With this in 
 place we have a reliable timeout mechanism for hung commands, currently set 
 at 30 seconds.
 - Add framework for registering init/cleanup routines for stateful RPCs to 
 clean up after themselves after a timeout.
 - Added the following RPCs: guest-file-{open,close,read,write,seek}, 
 guest-shutdown, guest-info, and removed stubs for guest-view-file (now 
 deprecated)
 - Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
 - Switched to a TCP-style host-initiated 3-way handshake for channel 
 negotiation, this simplifies client negotiation/interaction over the wire
 - Added configurable log level/log file/pid file options for guest agent
 - Various fixes for bugs/memory leaks and checkpatch.pl fixups
 
 ISSUES/TODOS:
 
 - Fix QMP proxy handling of error responses sent by guest agent, currently 
 ignored
 - Add unit tests for guest agent wire protocol
 - Add unit tests for QMP interfaces
 - Add host-side timeout mechanism for async QMP commands
 - Return error for guest commands if guest up event has not yet been recieved
 - Make QMP param names more consistent between related commands
 - Clean up logging
 

Hi,

I had a look through this patchset and generally it looks pretty good.
There were a few nits, and I ignored all the python gibberish to avoid
getting a headache.

Did you do anything with the fsfreeze patches, or were they dropped in
the migration to qapi?

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-21 Thread Michael Roth 

On 04/21/2011 04:46 AM, Jes Sorensen wrote:

On 04/18/11 17:02, Michael Roth wrote:

These apply on top of Anthony's glib tree, commit 
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained 
from:
git://repo.or.cz/qemu/mdroth.git qga_v2

Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider 
pulling these into your glib tree. The json fix-ups may need further 
evaluation, but I'm confident they're at least an improvement. The QAPI ones 
are mostly trivial fix-ups.

Changes since V1:

- Added guest agent worker thread to execute RPCs in the guest. With this in 
place we have a reliable timeout mechanism for hung commands, currently set at 
30 seconds.
- Add framework for registering init/cleanup routines for stateful RPCs to 
clean up after themselves after a timeout.
- Added the following RPCs: guest-file-{open,close,read,write,seek}, 
guest-shutdown, guest-info, and removed stubs for guest-view-file (now 
deprecated)
- Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
- Switched to a TCP-style host-initiated 3-way handshake for channel 
negotiation, this simplifies client negotiation/interaction over the wire
- Added configurable log level/log file/pid file options for guest agent
- Various fixes for bugs/memory leaks and checkpatch.pl fixups

ISSUES/TODOS:

- Fix QMP proxy handling of error responses sent by guest agent, currently 
ignored
- Add unit tests for guest agent wire protocol
- Add unit tests for QMP interfaces
- Add host-side timeout mechanism for async QMP commands
- Return error for guest commands if guest up event has not yet been recieved
- Make QMP param names more consistent between related commands
- Clean up logging



Hi,

I had a look through this patchset and generally it looks pretty good.
There were a few nits, and I ignored all the python gibberish to avoid
getting a headache.

Did you do anything with the fsfreeze patches, or were they dropped in
the migration to qapi?


They were pending some changes required on the agent side that weren't 
really addressed/doable until this patchset, namely:


1) server-side timeout mechanism to recover from RPCs that can hang 
indefinitely or take a really long time (fsfreeze, fopen, etc), 
currently it's 30 seconds, may need to bump it to 60 for fsfreeze, or 
potentially add an RPC to change the server-side timeout
2) a simple way to temporarily turn off logging so agent doesn't 
deadlock itself

3) a way to register a cleanup handler when a timeout occurs.
4) disabling RPCs where proper accounting/logging is required 
(guest-open-file, guest-shutdown, etc)


#4 isn't implemented...I think this could be done fairly in-evasively 
with something like:


Response important_rpc():
  if (!ga_log(syslog, LEVEL_CRITICAL, important stuff happening))
return ERROR_LOGGING_CURRENTLY_DISABLED
  ...

bool ga_log(log_domain, level, msg):
  if (log_domain == syslog)
if (!logging_enabled  is_critical(log_level))
  return False;
syslog(msg, ...)
  else
if (logging_enabled)
  normallog(msg, ...)
  return True

With that I think we could actually drop the fsfreeze stuff in. Thoughts?



Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-21 Thread Jes Sorensen 
On 04/18/11 17:02, Michael Roth wrote:
 These apply on top of Anthony's glib tree, commit 
 03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained 
 from:
 git://repo.or.cz/qemu/mdroth.git qga_v2
 
 Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider 
 pulling these into your glib tree. The json fix-ups may need further 
 evaluation, but I'm confident they're at least an improvement. The QAPI ones 
 are mostly trivial fix-ups.
 
 Changes since V1:
 
 - Added guest agent worker thread to execute RPCs in the guest. With this in 
 place we have a reliable timeout mechanism for hung commands, currently set 
 at 30 seconds.
 - Add framework for registering init/cleanup routines for stateful RPCs to 
 clean up after themselves after a timeout.
 - Added the following RPCs: guest-file-{open,close,read,write,seek}, 
 guest-shutdown, guest-info, and removed stubs for guest-view-file (now 
 deprecated)
 - Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
 - Switched to a TCP-style host-initiated 3-way handshake for channel 
 negotiation, this simplifies client negotiation/interaction over the wire
 - Added configurable log level/log file/pid file options for guest agent
 - Various fixes for bugs/memory leaks and checkpatch.pl fixups
 
 ISSUES/TODOS:
 
 - Fix QMP proxy handling of error responses sent by guest agent, currently 
 ignored
 - Add unit tests for guest agent wire protocol
 - Add unit tests for QMP interfaces
 - Add host-side timeout mechanism for async QMP commands
 - Return error for guest commands if guest up event has not yet been recieved
 - Make QMP param names more consistent between related commands
 - Clean up logging

Michael,

One thing I cannot seem to figure out with this tree - the agent
commands do not seem to show up in the monitor? What am I missing?

Cheers,
Jes

Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-21 Thread Michael Roth 

On 04/21/2011 09:10 AM, Jes Sorensen wrote:

On 04/18/11 17:02, Michael Roth wrote:

These apply on top of Anthony's glib tree, commit 
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained 
from:
git://repo.or.cz/qemu/mdroth.git qga_v2

Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider 
pulling these into your glib tree. The json fix-ups may need further 
evaluation, but I'm confident they're at least an improvement. The QAPI ones 
are mostly trivial fix-ups.

Changes since V1:

- Added guest agent worker thread to execute RPCs in the guest. With this in 
place we have a reliable timeout mechanism for hung commands, currently set at 
30 seconds.
- Add framework for registering init/cleanup routines for stateful RPCs to 
clean up after themselves after a timeout.
- Added the following RPCs: guest-file-{open,close,read,write,seek}, 
guest-shutdown, guest-info, and removed stubs for guest-view-file (now 
deprecated)
- Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
- Switched to a TCP-style host-initiated 3-way handshake for channel 
negotiation, this simplifies client negotiation/interaction over the wire
- Added configurable log level/log file/pid file options for guest agent
- Various fixes for bugs/memory leaks and checkpatch.pl fixups

ISSUES/TODOS:

- Fix QMP proxy handling of error responses sent by guest agent, currently 
ignored
- Add unit tests for guest agent wire protocol
- Add unit tests for QMP interfaces
- Add host-side timeout mechanism for async QMP commands
- Return error for guest commands if guest up event has not yet been recieved
- Make QMP param names more consistent between related commands
- Clean up logging


Michael,

One thing I cannot seem to figure out with this tree - the agent
commands do not seem to show up in the monitor? What am I missing?


Hmm, for some reason this email never hit my inbox.

You mean with the human monitor? Currently, with these new patches, 
we're QMP only. And most of the command names/semantics have changed as 
well. The qapi-schema.json changes in patch 16 have the new prototypes, 
and the 0 patch has some usage examples.




Cheers,
Jes

[Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

2011-04-18 Thread Michael Roth 
These apply on top of Anthony's glib tree, commit 
03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained 
from:
git://repo.or.cz/qemu/mdroth.git qga_v2

Patches 1-8 are general json/QAPI-related fixes. Anthony, please consider 
pulling these into your glib tree. The json fix-ups may need further 
evaluation, but I'm confident they're at least an improvement. The QAPI ones 
are mostly trivial fix-ups.

Changes since V1:

- Added guest agent worker thread to execute RPCs in the guest. With this in 
place we have a reliable timeout mechanism for hung commands, currently set at 
30 seconds.
- Add framework for registering init/cleanup routines for stateful RPCs to 
clean up after themselves after a timeout.
- Added the following RPCs: guest-file-{open,close,read,write,seek}, 
guest-shutdown, guest-info, and removed stubs for guest-view-file (now 
deprecated)
- Added GUEST_AGENT_UP/GUEST_AGENT_DOWN QMP events
- Switched to a TCP-style host-initiated 3-way handshake for channel 
negotiation, this simplifies client negotiation/interaction over the wire
- Added configurable log level/log file/pid file options for guest agent
- Various fixes for bugs/memory leaks and checkpatch.pl fixups

ISSUES/TODOS:

- Fix QMP proxy handling of error responses sent by guest agent, currently 
ignored
- Add unit tests for guest agent wire protocol
- Add unit tests for QMP interfaces
- Add host-side timeout mechanism for async QMP commands
- Return error for guest commands if guest up event has not yet been recieved
- Make QMP param names more consistent between related commands
- Clean up logging

OVERVIEW

For a better overview of what these patches are meant to accomplish, please 
reference the RFC for virtagent:

http://comments.gmane.org/gmane.comp.emulators.qemu/96096

These patches integrate the previous virtagent guest agent work directly in 
QAPI/QMP to leverage it's auto-generated marshalling code. This has numerous 
benefits:

 - addresses previous concerns over relying on external libraries to handle 
data encapsulation
 - reduces the need for manual unmarshalling of requests/responses, which makes 
adding new RPCs much safer/less error-prone, as well as cutting down on 
redundant code
 - QAPI documentation aligns completely with guest-side RPC implementation
 - is Just Better (TM)

BUILD/USAGE

build:
  ./configure --target-list=x86_64-softmmu
  make
  make qemu-ga #should be built on|for target guest

start guest:
  qemu \
  -drive file=/home/mdroth/vm/rhel6_64_base.raw,snapshot=off,if=virtio \
  -net nic,model=virtio,macaddr=52:54:00:12:34:00 \
  -net tap,script=/etc/qemu-ifup \
  -vnc :1 -m 1024 --enable-kvm \
  -chardev socket,path=/tmp/mon-qmp.sock,server,nowait,id=mon-qmp \
  -qmp mon-qmp \
  -chardev qmp_proxy,id=qmp_proxy \ 
  -device virtio-serial \
  -device virtserialport,chardev=qmp_proxy,name=qcg

use guest agent:
  ./qemu-ga -h
  ./qemu-ga -c virtio-serial -p /dev/virtio-ports/qcg

start/use qmp:
  mdroth@illuin:~$ sudo socat unix-connect:/tmp/mon-qmp.sock readline
  {QMP: {version: {qemu: {micro: 50, minor: 13, major: 0}, 
package: }, capabilities: []}}

  {execute:guest-info}
  {return: {}}

  {execute: guest-info}
  {return: {version: 1.0, timeout_ms: 3}}

  {execute:guest-file-open, 
arguments:{filename:/tmp/testqga,mode:w+}}
  {return: 0}
  {execute:guest-file-write, 
arguments:{filehandle:0,data_b64:aGVsbG8gd29ybGQhCg==,count:13}} // 
writes hello world!\n
  {return: {count: 13, eof: false}}

  {execute:guest-file-open, 
arguments:{filename:/tmp/testqga,mode:r}}
  {return: 1}
  {execute:guest-file-read, arguments:{filehandle:1,count:1024}}
  {return: {buf: aGVsbG8gd29ybGQhCg==, count: 13, eof: true}}
  {execute:guest-file-close,arguments:{filehandle:1}}
  {return: {}}

 Makefile|   15 +-
 Makefile.objs   |1 +
 configure   |6 +-
 json-lexer.c|   33 ++-
 json-lexer.h|1 +
 json-parser.c   |6 +-
 json-streamer.c |   35 ++-
 qapi-schema.json|  140 -
 qemu-char.c |   55 +++
 qemu-ga.c   |  711 +++
 qemu-sockets.c  |2 +-
 qga/guest-agent-command-state.c |   73 
 qga/guest-agent-commands.c  |  284 
 qga/guest-agent-core.c  |  139 
 qga/guest-agent-core.h  |   40 +++
 qga/guest-agent-worker.c|  173 ++
 qmp-core.c  |   13 +-
 qmp-core.h  |7 +-
 qmp-gen.py  |   15 +-
 qmp-proxy-core.h|   21 ++
 qmp-proxy.c |  294 
 vl.c|1 +
 22 files changed, 2023 insertions(+), 42 deletions(-)