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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]