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

[Michal Privoznik]

On 16.03.2012 15:49, Michael Roth wrote:
> 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.

Only once at the guest startup or libvirt daemon startup if the guest is
already running.
> 
> 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.

Since GA may come and go I don't see any guaranteed algorithm that would
work for 100%. And I try to avoid using timeouts for state changing
commands, because if I choose a timeout which can look reasonable now,
somebody will hit it sooner or later; take fs-freeze as example.
Moreover, if we timeout on a state changing command, libvirt would have
to keep track of such command anyway because if/when it returns, libvirt
must issue counter command right after: fs-freeze vs. fs-thaw. However,
only iff command returned successfully.
Things get complicated if two or more commands timeout, e.g. due to GA
not being running.
And since GA doesn't support passing ID into GA commands it's hard to
keep track which of expired commands succeeded and which failed. Okay,
nowdays GA executes commands sequentially, but that may change in the
future. We are not allowing timeouts on monitor neither.

Or maybe I am just too timid and see problems which are not really
problems :)

> 
> 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
>>
> 

Anyway, thank you for clarify; I'll stick to guest-sync then.

Michal