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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 07/28/2011 03:54 AM, Jes Sorensen wrote:
> 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.
>

I'd prefer this approach as well. We could potentially implement it with 
a more general mechanism for executing scripts in the guest for whatever 
reason, rather than an fsfreeze-specific one.

Let the management layer handle the orchestration between the 2. Whether 
the freeze is kernel-driven or not I think can go either way, though the 
potential issues I mentioned in response the Fernando's post seem to 
those proposed changes are required for a "proper" guest agent 
implementation, and at that point we're talking about kernel changes 
either way for the functionality we ultimately want.

I think there may still be value in retaining the current fsfreeze 
support in the agent for older guests, however. What I'm convinced of 
now though is that the operation should not be tethered to the 
application callback operation, since that's applicable to other 
potential fsfreeze mechanisms.

> Cheers,
> Jes