From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8YTh-0005TM-8z for qemu-devel@nongnu.org; Fri, 16 Mar 2012 10:50:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8YTc-00064x-9h for qemu-devel@nongnu.org; Fri, 16 Mar 2012 10:50:00 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:34590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8YTc-00064p-2r for qemu-devel@nongnu.org; Fri, 16 Mar 2012 10:49:56 -0400 Received: by yhoo21 with SMTP id o21so4944850yho.4 for ; Fri, 16 Mar 2012 07:49:54 -0700 (PDT) Sender: fluxion Date: Fri, 16 Mar 2012 09:49:47 -0500 From: Michael Roth Message-ID: <20120316144947.GA2933@illuin> References: <4F63366E.8090902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F63366E.8090902@redhat.com> Subject: Re: [Qemu-devel] Guest-sync-delimited and sentinel issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michal Privoznik Cc: QEMU Developers 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 >