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