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

[Tomoki Sekiyama]

On 3/27/14 18:27 , "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.
>
>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 sounds reasonable for me to add disks parameters.
I will try adding them in next version. Then the api will look like:

int virDomainFSFreeze(virDomainPtr dom, char** disks, int ndisks, unsigned
int flags);
 and
int virDomainFSThaw(virDomainPtr dom, unsigned int flags);


I feel that thaw api shouldn't have disks parameter and thaw every frozen
disk
in order to simplify fsfreeze exclusion. Is it acceptable?


BTW, in current qemu-kvm, disk device names in Linux guests don't seem to
always
correspond to that is specified by libvirt (e.g. the first virtio storage
is
named "vda" even if it is specified "vdz" in the libvirt's xml). Until
this is
resolved, guest agent may ignore the disks parameter and fallback to
freezing
all mounted filesystems. But still, having disks parameter in the API level
would be good for future extension.


>I feel a bit bad that this was posted before freeze of 1.2.3, but we
>don't have it in yet, which makes it harder to commit until the 1.2.4
>cycle.  On the other hand, if we decide the API needs to be tweaked to
>add parameters for full usability, then maybe it's a good thing we don't
>have it in yet.

And I will update API version number for the API to 1.2.4 in next patch. :)

Thanks,
-- 
Tomoki Sekiyama