From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmMO2-0006QZ-4h for qemu-devel@nongnu.org; Thu, 28 Jul 2011 04:56:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmMO0-0002OP-Tk for qemu-devel@nongnu.org; Thu, 28 Jul 2011 04:56:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmMO0-0002Nw-GM for qemu-devel@nongnu.org; Thu, 28 Jul 2011 04:56:08 -0400 Message-ID: <4E3123AB.4030600@redhat.com> Date: Thu, 28 Jul 2011 10:54:03 +0200 From: Jes Sorensen MIME-Version: 1.0 References: <20110727152457.GK18528@redhat.com> <4E3037B1.7070301@linux.vnet.ibm.com> <20110727164054.GA3087@redhat.com> In-Reply-To: <20110727164054.GA3087@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Andrea Arcangeli Cc: Luiz Capitulino , Michael Roth , qemu-devel@nongnu.org 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