[libvirt] [PATCH v4 0/5] Expose FSFreeze/FSThaw within the guest as API

[Jon Bernard]

* Eric Blake <eblake at redhat.com> wrote:
> On 03/27/2014 04:21 PM, Jon Bernard wrote:
> > * Tomoki Sekiyama <tomoki.sekiyama at hds.com> wrote:
> >> Hello,
> >>
> >> This is patchset v4 to add FSFreeze/FSThaw API for custom disk snapshotting.
> > 
> > This patchset works for my tests.  Without pausing the guest I am able
> > to quiesce all attached volumes.  Does there exists an option to create
> > a snapshot of only one (or some) of the volumes attached to a particular
> > instance?
> 
> Interesting question.  The virDomainSnapshotCreateXML call can quiesce a
> subset of disks (namely, only the disks that were specified in the
> snapshot).  But as currently designed, the FSFreeze/FSThaw API have no
> way to specify a subset of disks; it is an all-or-none proposition.

Yes, if a user intends to only snapshot a subset of the attached volumes
then quiescing all volumes would be unnecessary.  I can think of
pathological cases where the one one volume you don't need to snapshot
is under heavy I/O and that causes the fsfreeze() to timeout and fail
the entire operation (or something similar).

> Perhaps that means the API is not quite right, and that we need a
> 'char**disks, int ndisks' parameter pair; if 'NULL, 0', we do all disks,
> if non-NULL, then we freeze only the listed set of disks (doing the same
> lookup for disks as for other APIs).

This is the direction I would lean in, IMO.  In the case of Nova
(openstack), the user would want to create a consistent set of snapshots
for one, some, or all of the attached volumes.  Having the granularity
to only freeze, snapshot, and thaw the volumes in question would mean
only the required amount of work is performed.

One thing comes to mind: once volumes are quiesced, qemu-img could be
used directly to create the snapshot.  In the case of iSCSI-attached
volumes, a remote snapshot command could be issued to create a snapshot.
Once all have completed the guest then thawed.

For local volumes, using qemu-img seems cumbersome to me.  I feel there
should be a libvirt call to handle at least the local volumes.

-- 
Jon