On Wed, Feb 12, 2014 at 02:05:11PM -0700, Eric Blake wrote: > On 02/12/2014 01:45 PM, Marcelo Tosatti wrote: > > On Wed, Feb 12, 2014 at 10:22:11AM +0000, Daniel P. Berrange wrote: > >> I agree that this should be a completely separate command, not > >> merely a flag to the Resume API. The reason is that you cannot > >> do sensible error reporting if you overload this in one API > >> call. ie consider that resuming the CPUs succeeds, but syncing > >> time fails. If you return "success" to the caller you are lieing > >> about the result of time sync. If you return "error" to the caller > >> you are lieing about the result of resuming the CPUs. > >> > >> If there is a separate API to invoke then the caller can clearly > >> see which operation succeeded vs failed. > > > > Well then just require a new guest agent command. No need > > for a separate command. > > > > Going from "resume" to "resume-and-sync" versus > > > > Going from "resume" to "resume; send-guest-agent-command" > > > > Is not very different is it? In both cases qemu guest agent channel > > must be operational. > > You're confusing things. 'resume' is a command to qemu. 'sync' is a > command to the guest agent. The guest agent can't respond unless the > guest is running. If 'resume' fails, the guest is not running. But if > 'sync' fails, the guest is necessarily in a different state than when > you started. Having to report failure after the guest ran an > indeterminate number of instructions is not good. > > The guest agent is not in charge of resume, therefore adding a guest > agent command to do resume-and-sync is not possible. > > And qemu is not in charge of talking to the guest, only the agent is. > So adding a new qemu command to resume-and-sync is not possible. > > We really are talking about two disparate operations by two different > actors, and where failure of the second action cannot be rolled back to > the state of the first action. Yes, exactly, unless you can atomically succeed or fail the whole thing without side-effects they must be separate APIs. It is impossible to rollback execution of the guest after resuming it, so that's a blocking factor forcing separate APIs for this task. Doing a single monitor command in QEMU can't magically solve this as Eric describes. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list