On 3/27/14 20:32 , "Eric Blake" <eblake@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list