On 3/27/14 18:27 , "Eric Blake" <eblake@xxxxxxxxxx> wrote: >On 03/27/2014 04:21 PM, Jon Bernard wrote: >> * Tomoki Sekiyama <tomoki.sekiyama@xxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list