On Mon, May 14, 2012 at 11:17:18AM -0600, Eric Blake wrote: > On 05/14/2012 11:06 AM, Michal Privoznik wrote: > > On 11.05.2012 21:19, Luiz Capitulino wrote: > >> The main motivation for this series is fixing two possible race conditions > >> in the guest-suspend-* API due to the complexity that arose from the way > >> we handle terminated children processes today. Full details in the first > >> patch. > >> > >> This series applies on top of my two other qemu-ga series submitted > >> previously: > >> > >> http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00999.html > >> > >> http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01507.html > >> > >> qapi-schema-guest.json | 56 ++++++++++------ > >> qapi/qmp-core.h | 10 ++- > >> qapi/qmp-dispatch.c | 8 ++- > >> qapi/qmp-registry.c | 4 +- > >> qemu-ga.c | 40 ++++++------ > >> qga/commands-posix.c | 162 > >> ++++++++++++++++++---------------------------- > >> qga/guest-agent-core.h | 4 ++ > >> scripts/qapi-commands.py | 14 +++- > >> 8 files changed, 154 insertions(+), 144 deletions(-) > >> > > > > Okay, this is definitely an enhancement and fix of bogus implementation. > > One thing that I'd like to ask is - how can user distinguish between > > these implementations. I am asking basically from libvirt POV. > > Because if I assume I am dealing with the previous implementation and > > thus waiting for the {'return':{}} before I can return form an API, but > > the GA actually uses the new implementation I will block endlessly. > > I think the point was that you would block endlessly waiting for the > {'return':{}} anyways, even with the old implementation, because there > was no guarantee that the guest agent could issue the reply in a timely > manner. Therefore, the only sane implementation in libvirt is to assume > that success will not be reported via the guest agent, and that libvirt > must _always_ probe for the listed side effects (a change in guest > status, qemu exiting, an event, or so forth), and optionally have a > timeout if the associated timeout does not occur in a reasonable time.
Additionally, *all* commands carry the risk that qemu-ga can die (killed, crashed, guest reboots, not being installed to begin with, etc) before issuing a response, so a timeout mechanism *must* be in place if it blocks libvirt. Let me know if it's unclear how timeout+reset is to be implemented/used. I've captured most of the ins/outs here but I realize it's still a bit of a headache: http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol > > -- > Eric Blake ebl...@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
