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.
I'll go write a virsh alias and virt-manager patch.
(BTW, error reporting would be in the libvirt logs,
GuestAgentError with all the details why time-sync failed).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org