On 07.11.2013 01:31, 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)) > > These would be useful in the case a guest has a disk device with its own > snapshot feature, such as cinder volumes in OpenStack configuration. > In such cases, libvirt clients want to issue fsfreeze/fsthaw before/after > taking the disk snapshot. > > Currently we can execute them using virDomainQemuAgentCommand(). (e.g. > virsh qemu-agent-command dom '{"execute":"guest-fsfreeze-freeze"}' ) > > However, this is exposing internal implementation too much. And it > cannot leverage future implementation for the other hypervisors. > So it would be nice if we have well-defined API for fsfreeze/fsthaw. > > If there is no plan for these API and this is acceptable, I will try to > implement this. > Any comments are welcome. I am not aware of somebody wanting these APIs exposed hence I don't know if somebody is working on it. But since there is a clear usage scenario I'd say go for it.

On 11/7/13 4:01 , "Daniel P. Berrange" <berrange(a)redhat.com&gt; wrote: >On Thu, Nov 07, 2013 at 09:39:01AM +0100, Michal Privoznik wrote: >> On 07.11.2013 01:31, 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)) >> > >> > These would be useful in the case a guest has a disk device with its >>own >> > snapshot feature, such as cinder volumes in OpenStack configuration. >> > In such cases, libvirt clients want to issue fsfreeze/fsthaw >>before/after >> > taking the disk snapshot. >> > >> > Currently we can execute them using virDomainQemuAgentCommand(). (e.g. >> > virsh qemu-agent-command dom '{"execute":"guest-fsfreeze-freeze"}' ) >> > >> > However, this is exposing internal implementation too much. And it >> > cannot leverage future implementation for the other hypervisors. >> > So it would be nice if we have well-defined API for fsfreeze/fsthaw. >> > >> > If there is no plan for these API and this is acceptable, I will try >>to >> > implement this. >> > Any comments are welcome. >> >> I am not aware of somebody wanting these APIs exposed hence I don't know >> if somebody is working on it. But since there is a clear usage scenario >> I'd say go for it. > >We already support this QEMU agent commands in libvirt. We decided not >to expose them explicitly as APIs, but instead wire them upto the impl >of the disk snapshot APIs when VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE is >used. > >Furthermore, OpenStack already has support for using this flag when >doing snapshots, so I don't think we need any more work here. > >Daniel AFAIK, VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE is used in openstack only when glusterfs is used as volume backend which uses external qcow2 snapshot. In the other cases, it uses own implementation instead of libvirt snapshot API, to exploit native snapshot features of various storages, such as LVM (over iSCSI), enterprise storages, and so on. For these cases, fsfreeze API (without taking snapshot) is useful.

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.

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.