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 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.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list