On 11/8/13 0:25 , "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: >On Thu, Nov 07, 2013 at 10:39:08AM -0700, Eric Blake 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 don't see how 'callback' is going to work, since it would have >to run client side, but everything else is server side. I'm not >entirely comfortable with the callback idea in general for that - it >seems it could create alot of "interesting" scenarios for us to worry >about, in particular around re-entrancy & synchronization. Thank you for the comments. I've investigated the current event mechanism of libvirt, and now thinking that it is difficult to be applied callback that runs in the client side.... It may require a new event mechanism that is sent only to the specific client, and that has notifier when callback is finished. However, it looks like overdesign for fsfreeze, so virDomainFSFreeze(domain,timeout,flags) and virDomainFSThaw(domain,timeout,flags) is much simpler. On Thu, Nov 07, 2013 at 10:39:08AM -0700, Eric Blake wrote: > 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. We should track fsfreeze status and fail the snapshot API with QUIESCE flag while it is frozen, instead of making this single APIs. Anyway, some block APIs is needed to be executable while guest filesystems are frozen to do a custom snapshot. Thanks, -- Tomoki Sekiyama -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list