qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Michal Privoznik <mprivozn@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Guest-sync-delimited and sentinel issue
Date: Fri, 16 Mar 2012 09:49:47 -0500	[thread overview]
Message-ID: <20120316144947.GA2933@illuin> (raw)
In-Reply-To: <4F63366E.8090902@redhat.com>

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	other threads:[~2012-03-16 14:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-16 12:47 [Qemu-devel] Guest-sync-delimited and sentinel issue Michal Privoznik
2012-03-16 14:49 ` Michael Roth [this message]
2012-03-16 16:04   ` Michal Privoznik
2012-03-16 17:26     ` Michael Roth
2012-03-16 15:07 ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120316144947.GA2933@illuin \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).