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

[Tomoki Sekiyama]

On 3/27/14 20:32 , "Eric Blake" <eblake at redhat.com> wrote:
>On 03/27/2014 05:54 PM, Tomoki Sekiyama wrote:
>> 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?
>
>Maybe, maybe not.  It means on a guest with 2 disks, I can't freeze one,
>then freeze the second - I can only have one atomic freeze at a time,
>and therefore thaw needs no parameters because it is always thawing the
>most recent freeze action.
>
>But we already know from painful experience that assuming at most one
>active job at a time doesn't scale well.  Maybe it should be:
>
>int virDomainFSFreeze(...char **disks...) returns a handle
>virDomainFSThaw(virDomainPtr dom, int handle, unsigned int flags);
>
>where FSThaw then thaws according to the handle returned by a freeze.
>That would allow me to do:
>
>interleaved subsets:
>freeze A => returns 1
>freeze B => returns 2
>thaw 1 => thaws A
>thaw 2 => thaws B
>
>nested subsets
>freeze A => returns 3
>freeze B => returns 4
>thaw 4 => thaws B
>thaw 3 => thaws A

What should happen when freezing the same disk is requested?
Currently it causes error. Another model can be counting freeze request
and defer thawing until thaw is requested the same time:

freeze A,B => returns 1  [counter A:1 B:1]
freeze A   => returns 2  [counter A:2 B:1]
thaw 1     => thaw B     [counter A:1 B:0]
thaw 2     => thaw A     [counter A:0 B:0]


And in qemu driver, until the issue about mapping disk name of guests and
libvirt is resolved, we could fallback to freeze every filesystem while
the counter > 0:

freeze A,B => returns 1 [counter 1] freeze every fs
freeze A   => returns 2 [counter 2]
thaw 1     =>           [counter 1]
thaw 2     =>           [counter 0] thaw every fs

Another aspect we need to consider is that freezing is done on filesystem
level, not on disk level. So if the filesystems lay on multiple disks
using LVM and so on, the situation will be more complex. Maybe the fs
should be frozen if a part of its disks are contained in the request,
although that wouldn't be useful for consistent snapshotting....



>> 
>> 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).
>
>Correct.  Libvirt specifies destination names as a hint that must be
>unique to libvirt, but which has no bearing on the names used by the
>guest.
>
>> 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.
>
>Hmm, interesting point.  Really, that means we want some way to map the
>strings understood by libvirt API into the disk names understood by the
>guest agent, and I don't know if we have such a means.  But I guess this
>is an issue even for the existing virDomainSnapshotCreateXML with the
>quiesce flag, so it's not a new problem.

Was there any discussion about this issue before?

Thanks,
Tomoki Sekiyama