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

[Andrea Arcangeli <aarcange@redhat.com>]

On Wed, Jul 27, 2011 at 11:34:44AM -0500, Anthony Liguori wrote:
> Currently, QEMU doesn't know about fsfreeze.  I don't think it ever will 
> either.

Ah, sorry thanks for the correction, it's some other repo that you
were modifying (qga).

> One challenge though is that it's highly desirable to have script hooks 
> as part of the freeze process to let other userspace applications 
> participate which means you will always need some userspace daemon to 
> kick things off.
> 
> Instead of having a virtio-fsfreeze, I think it would be better to think 
> about if the kernel needs a higher level interface such that the 
> userspace operation is dirt-simple.
> 
> But I don't see a way to avoid userspace involvement in this set of 
> operations unfortunately.

A /dev/virtio-fsfreeze chardevice created by udev when
virtio-fsfreeze.ko is loaded may be enough to do it. Or maybe it
should be a host kernel solution /dev/fsfreeze that talks with
fsfreeze (not just the virtio case).

The apps liekly must be modified for this, I doubt the scripts would
do much on their own (they'd likely just tell the app to do something
through an unix domain socket) but if scripts are needed the agent
could open that chardev instead of talking QMP/QAPI.

It also depends if people prefers a single agent do it all, or a
fsfreeze agent and some other agent for something else. Even if they
want a single agent for everything they could still have it talk
QMP/QAPI on the virtio-serial vmchannel for everything else and open
/dev/virtio-fsfreeze or /dev/freeze if available.

It's up to you... you understand the customer requirements better. For
me a kernel update and no agent sounds nicer and looks more reliable
considering what fsfreeze does.