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

[Michal Privoznik]

On 30.03.2012 16:31, Jiri Denemark wrote:
> 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.
> 

Thanks pushed.
> 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

Yeah, I'll post follow up patch once we're after release.

Michal