Re: [libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

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.