qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Guest-sync-delimited and sentinel issue


From: Michael Roth
Subject: Re: [Qemu-devel] Guest-sync-delimited and sentinel issue
Date: Fri, 16 Mar 2012 09:49:47 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Mar 16, 2012 at 01:47:42PM +0100, Michal Privoznik wrote:
> Hi guys,
> 
> I was just implementing support for guest-sync-delimited into libvirt. My 
> intent is to issue this command prior any other command to determine if GA is 
> available or not. The big advantage is - it doesn't change the state of the 
> guest so from libvirt POV it's harmless. The other big advantage is this 
> sentinel byte 0xFF which is supposed to flush all unprocessed (and possibly 
> stale) data from previous unsuccessful tries.

Are you opening the qemu-ga socket prior to each command? Or just
once at startup? If you're only opening it once, it should be sufficient
to do the guest-sync/guest-sync-delimited exchange just once at that time,
since the streams are presumably synced at that point, and after that only if
you get a client-side timeout.

Issuing it prior to each command doesn't guarantee that the agent will
be available to handle the command, so you still need be prepared to
handle a timeout + re-sync. It does reduce the chances of timing out on
doing something that affects guest state though... but if that's the
intention here I would recommend just using 'guest-ping', which should
work reliably so long as you always re-sync on connect and after
client-side timeouts.

But it doesn't really matter either way, all I'm really getting at is that
scanning for the 0xFF delimiter in the response shouldn't be *necessary* in
this case. But there's no harm in using it that way. You don't need to
precede the request with 0xFF if you're just using it to probe for the
agent though, and you probably wouldn't want to given that it results in
2 responses:

> 
> As written in documentation, this command will output sentinel byte to the 
> guest agent socket. This works perfectly. However, it is advised in the very 
> same documentation to prepend this command with the sentinel as well allowing 
> GA parser flush. But this doesn't work for me completely. All I can get is:
> 
> $ echo -e "\xFF{\"execute\":\"guest-sync-delimited\", 
> \"arguments\":{\"id\":1234}}" | nc -U /tmp/ga.sock | hexdump -C
> nc: using stream socket
> 00000000  7b 22 65 72 72 6f 72 22  3a 20 7b 22 63 6c 61 73  |{"error": {"clas|
> 00000010  73 22 3a 20 22 4a 53 4f  4e 50 61 72 73 69 6e 67  |s": "JSONParsing|
> 00000020  22 2c 20 22 64 61 74 61  22 3a 20 7b 7d 7d 7d 0a  |", "data": {}}}.|
> 00000030  ff 7b 22 72 65 74 75 72  6e 22 3a 20 31 32 33 34  |.{"return": 1234|
> 00000040  7d 0a                                             |}.|
> 00000042
> 
> The problem is - GA has difficulties with parsing sentinel, although the 
> reply is correct, indeed.
> Therefore my question is - should I just drop passing sentinel to GA? And 
> even if this is fixed, How should I deal with older releases which have this 
> bug?

Sorry, I didn't document this properly. Haven't tested host->guest flush
in a while and got it in my head that it was handled silently, but what
you're seeing has actually always been the observed/intended behavior.

Depending on how you've implemented guest-sync-delimited it might not make
a difference though. If you're just ignoring any data up until you see
the 0xFF sentinel value then the error is silently thrown away as garbage. The
semantics of the command are that you may read garbage prior to the
sentinel+response, it's just that when preceeding the request with the
sentinel this is *always* the case.

Otherwise, if you're handling it like a "normal" request, when sending the 0xFF
you would treat it basically as a "flush" command that always returns a
JSONParsing error. It's not pretty because we're relying on the json
lexer/parser layer for this handling, but it should work reliably for all
current/previous versions of qemu-ga.

I'll make sure to fix up the documentation.
> 
> Regards,
> Michal
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]