On 11/7/13 14:05 , "Doug Goldstein" <cardoe@xxxxxxxxxx> wrote: >On Thu, Nov 7, 2013 at 11:39 AM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> On 11/06/2013 05:31 PM, Tomoki Sekiyama wrote: >>> Hi all, >>> >>> Is there any plans to add APIs to execute fsfreeze/fsthaw in qemu >>>guests? >>> (something like virDomainFSFreeze(domain,timeout,flags) and >>> virDomainFSThaw(domain,timeout,flags)) >> >> I'm wondering if it might be better to have a single command with a >> callback argument, something like: >> >> virDomainQuiese(domain, timeout, callback, opaque, flags) >> >> which calls callback(domain, opaque) at the right point in time. I'm >> just a bit worried that since the freeze/thaw sequence is already >> handled as a pair by the QUIESCE flag of snapshot creation that exposing >> it as two non-atomic APIs may lead to inconsistent states that we'd have >> a hard time tracking which commands are allowed in which state. With >> only a single command and a callback, we have guaranteed semantics that >> all other API are locked out by our normal job mechanism, and that we >> can pair the freeze/thaw under the hood just as we do in snapshots. > >I think this is a much better approach. We could arguably refactor the >snapshot code to use this as well. > This sounds reasonable for me. Thanks for your suggestion. Can we call virDomainBlockRebase() and BlockJobInfo()/BlockJobAbort() for the rebase operation in the callback? OpensStack is using these while image snapshot for now. For other kinds of volumes, other APIs might also be used. Tomoki Sekiyama -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list