Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel

[Jes Sorensen]

On 07/27/11 18:40, Andrea Arcangeli wrote:
>> Another thing to note is that snapshotting is not necessarily something 
>> > that should be completely transparent to the guest. One of the planned 
>> > future features for the guest agent (mentioned in the snapshot wiki, and 
>> > a common use case that I've seen come up elsewhere as well in the 
>> > context of database applications), is a way for userspace applications 
>> > to register callbacks to be made in the event of a freeze (dumping 
>> > application-managed caches to disk and things along that line). The 
> Not sure if the scripts are really needed or if they would just open a
> brand new fsfreeze specific unix domain socket (created by the
> database) to tell the database to freeze.
> 
> If the latter is the case, then it'd be better rather than changing
> the database to open unix domain socket so the script can connect to
> it when invoked (or maybe to just add some new function to the
> protocol of an existing open unix domain socket), to instead change
> the database to open a /dev/virtio-fsfreeze device, created by the
> virtio-fsfreeze.ko virtio driver through udev. The database would poll
> it, and it could read the request to freeze, and write into it that it
> finished freezing when done. Then when all openers of the device
> freezed, the virtio-fsfreeze.ko would go ahead freezing all the
> filesystems, and then tell qemu when it's finished freezing. Then qemu
> can finally block all the I/O and tell libvirt to go ahead with the
> snapshot.

I think it could also be a combined operation, ie. having the freeze
happen in the kernel, but doing the callouts using a userspace daemon. I
like the userspace daemon for the callouts because it allows providing a
more sophisticated API than if we provide just a socket like interface.
In addition the callout is less critical wrt crashes than the fsfreeze
operations.

Cheers,
Jes