On Thu, Feb 13, 2014 at 03:02:38PM +0100, Michal Privoznik wrote:
> On 13.02.2014 14:32, Eric Blake wrote:
> >On 02/13/2014 02:09 AM, Michal Privoznik wrote:
> >
> >>>Maybe even both additions would be appropriate (a knob for automatic
> >>>libvirt syncing as well as a new API for explicit syncing outside the
> >>>events where libvirt would normally do it automatically).
> >>
> >>I don't think we should add the <on_resume/> element. After all, it
> >>would be the same as:
> >>
> >>virDomainResumeFlags(dom, VIR_SYNC_TIME)
> >>
> >>which as Dan correctly argues, makes sensible error reporting
> >>impossible. If the domain is resumed, libvirt should execute the
> >><on_resume/> action, which may fail.
> >
> >Or maybe we document that the virDomainResume() api tracks just the
> >resume state, then we add a new libvirt event that says the result of
> >any attempt at a sync operation. Then when you resume, and <on_resume>
> >says to attempt an auto-sync, then you can also listen for the libvirt
> >event that tells you the status of the sync (whether it succeeded (and
> >to what timestamp) or failed).
I think that leads to a pretty unpleasant usage pattern for
applications. eg instead of just getting an exception from
a dedicated API call in python, the app has to setup an event
loop thread and wait around in the hope an event may arrive
at some point after the API call. I don't see any compelling
reason why we want to make such an unpleasant API out of
virDomainResume, when we can just create a dedicated API
that does what we need.
> I think we are going the most complicated way here. Again. We are
> not in freeze so there's still time for new APIs. But then again,
> prior to posting patches to the libvirt list, I'd expect qemu to be
> patched already (I've proposed patch on the qemu-devel list and it
> got acked but not merged yet). My requirement may feel unnatural for
> somebody, but it wouldn't be for the first time that libvirt
> implemented something with blindly trusting in the design/API that
> was just discussed on the qemu-devel. Unfortunately for us, the
> design/API had changed leaving libvirt hanging in the air. Once the
> qemu patch is merged, it serves to me as a kind of guarantee that
> there is wide consensus on the design / API and it will not change
> (of course, it's get written in stone after the release, but I'm
> just fine with pushed-to-git).
>
> Having said that, I have patches that add virDomain{Get,Set}Time
> ready. Even though I need to polish them a bit before they are ready
> to send.
Might as well post them for review when you have them ready, even
if QEMU isn't merged. Worst case, we ACK them, but delay merging
them in libvirt until QEMU side is merged.
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