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

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