From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmSU5-0003J3-UQ for qemu-devel@nongnu.org; Thu, 28 Jul 2011 11:26:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmSU2-00019O-U7 for qemu-devel@nongnu.org; Thu, 28 Jul 2011 11:26:49 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:43847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmSU2-00018T-Nh for qemu-devel@nongnu.org; Thu, 28 Jul 2011 11:26:46 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p6SF135a019579 for ; Thu, 28 Jul 2011 11:01:03 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p6SFQYFx991450 for ; Thu, 28 Jul 2011 11:26:34 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p6SBQLHU002016 for ; Thu, 28 Jul 2011 08:26:21 -0300 Message-ID: <4E317FA9.4000901@linux.vnet.ibm.com> Date: Thu, 28 Jul 2011 10:26:33 -0500 From: Michael Roth MIME-Version: 1.0 References: <20110727152457.GK18528@redhat.com> <4E3037B1.7070301@linux.vnet.ibm.com> <20110727164054.GA3087@redhat.com> <4E3123AB.4030600@redhat.com> In-Reply-To: <4E3123AB.4030600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Jes Sorensen Cc: Andrea Arcangeli , qemu-devel@nongnu.org, Luiz Capitulino 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