From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm7JG-00034I-6z for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:50:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm7JD-00085O-Rd for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:50:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm7JD-000853-Kc for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:50:11 -0400 Date: Wed, 27 Jul 2011 18:50:03 +0200 From: Andrea Arcangeli Message-ID: <20110727165003.GB3087@redhat.com> References: <20110727152457.GK18528@redhat.com> <4E303E24.3050800@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E303E24.3050800@codemonkey.ws> Subject: Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Michael Roth , Jes Sorensen , qemu-devel@nongnu.org, Luiz Capitulino 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.