From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuneO-0008Tj-6h for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:12:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuneH-0004Xn-Ua for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:12:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuneH-0004XZ-NX for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:12:05 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q17GC475025541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Feb 2012 11:12:04 -0500 Message-ID: <4F314D4D.30402@redhat.com> Date: Tue, 07 Feb 2012 09:11:57 -0700 From: Eric Blake MIME-Version: 1.0 References: <20120207151833.GP3785@redhat.com> <4F314823.7050705@redhat.com> In-Reply-To: <4F314823.7050705@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC31B521B88EC96C4C1C009B3" Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu_agent: Issue guest-sync prior to every command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michal Privoznik Cc: libvir-list@redhat.com, QEMU Developers This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC31B521B88EC96C4C1C009B3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/07/2012 08:49 AM, Michal Privoznik wrote: >> We could still timeout the 'fs-freeze' command after 30 seconds >> or so. Given that we issue the guest-resync command, we'll be >> able to automatically re-sync the JSON protocol by dropping the >> later arriving fs-freeze reply (if any). >=20 > I don't think this is a good idea. I've chosen 'fs-freeze' intentionall= y > :) It's something that actually might take ages - to sync disks (which > is what current implementation does). Therefore if we set any timeout > for regular commands we may get into inconsistent state: >=20 > 1) issue fs-freeze > 2) timeout and return error (everybody thinks fs is not frozen) > 3) receive "okay, frozen" from GA Question for the qemu-folks: We've already documented that qemu-ga must be treated as an asynchronous interface; callers cannot expect the client to reliably reply, and must always have a timeout mechanism in place. Doesn't that mean that any guest agent command that might potentially be long-running should instead be broken up into multiple commands, one to start the process, and another to query whether the process has been completed? That is, since fs-freeze might be potentially long-running, should we break it into multiple commands: fs-freeze-async requests that a freeze be started, and an immediate ack returned if the process is started fs-freeze-query returns the status of whether the system is thawed, frozen, or in the process of transitioning libvirt would then issue a guest-sync with reasonable timeout (to ensure the agent is currently responsive, if it fails, the agent is not available), then an fs-freeze-async with reasonable timeout (if that fails, the freeze is not possible), then periodic fs-freeze-query until the freeze completes (if any of them fail, assume the agent restarted, but that the system is frozen, and therefore, libvirt should send an fs-thaw command prior to returning failure, just in case). >> >> According to the 'guest-sync' QMP spec, we need to send the magic byte= >> '0xFF' immediately before the guest-sync command data is sent. >=20 > Yeah, and probably switch to new guest-sync-delimited command as soon a= s > it's upstream. If I'm understanding the recent proposals correctly, guest-sync exists in 1.0 guest agents, but not guest-sync-delimited; we can always send 0xff, but we can only expect to receive 0xff if we use guest-sync-delimited which means we need to probe to see if the guest agent understands guest-sync-delimited. Is it safe to send a 1.0 guest a command it doesn't understand, like guest-sync-delimited, and expect to get a reliable error message in reply? --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC31B521B88EC96C4C1C009B3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPMU1OAAoJEKeha0olJ0Nq6/QH/0UmzdRfPbx54jekR17JwRRm 2Dd+syXlHVD+9+6GKcN1hZtXgoEpwYekO3IEy+XSfuE5l/TiA+z0oqgeaLP2xaky OJxOpUAIGDeu5RWvLdRF6jSv2rDoq72lDz+sC+o8LdE9v1r1F+NS1EPNfkUlACSF JEg35a6G1Ei6L4htEVFfTVpeIUw4s4N2LpmtXr1Ah/hCaflNe5wAuq2YJ4bwW8+s awwaDC4AB0q1+mgbuAze+d5MIgavcFwZ8IgTOnXIo7KPhPn9Ev3ATxAIh0w02CcE bz8zX+qIzf+HG+hWaLAphx9e9Uii3RZK3ZOS6R/xKjwrUYPPosaJ1AvwVbvGmJA= =KMPR -----END PGP SIGNATURE----- --------------enigC31B521B88EC96C4C1C009B3--