[libvirt] [PATCH v2] qemu_agent: Issue guest-sync prior to every command

[Jiri Denemark]

On Fri, Mar 16, 2012 at 17:35:09 +0100, Michal Privoznik wrote:
> If we issue guest command and GA is not running, the issuing thread
> will block endlessly. We can check for GA presence by issuing
> guest-sync with unique ID (timestamp). We don't want to issue real
> command as even if GA is not running, once it is started, it process
> all commands written to GA socket.
> ---
> diff to v1:
> - don't keep list of issued IDs because it's pointless
> 
> Some background on this:
> I've intended to switch to new guest-sync-delimited and use
> older guest-sync for older GA. However, since we don't use
> stream base implementation but use new line as delimiter for
> GA responses we don't need GA to issue sentinel byte 0xFF for us:
> 
>   http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol
> 
> Moreover, since we are using guest-sync just for detecting GA, it is
> not necessary to use sentinel byte at all:
> 
>   http://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg03278.html
> 
>  src/qemu/qemu_agent.c |  134 ++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 128 insertions(+), 6 deletions(-)

ACK, but don't forget to run make syntax-check before pushing to fix your
violation of recently added sizeof() rule.

Anyway, there is a small chance the guest-agent will crash after sending us a
response to guest-sync but before it can process the real command. Current
code will just hang waiting for the reply. We were discussing this issue with
Michal and came up with a possible solution:

- use timeouts for all ga commands
- any code sending ga command has to register a callback which will be used in
  case the command takes longer than timeout; in that case the caller already
  exited with error and the callback will make sure to undo any changes the
  command (which we thought was never acted upon) made; e.g., it will unfreeze
  guest's filesystem after we didn't get a reply to freeze in time
- when a new command is about to be issued, guest-sync is called (already
  done) and getting reply to it removes any callbacks since we know it won't
  be processed
- anytime the callback is present, we may report that guest agent is not
  responding to us using domcontrol (if possible) or using a new api

Jirka