From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qq85J-0005z9-6L for qemu-devel@nongnu.org; Sun, 07 Aug 2011 14:28:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qq85I-0000zP-Bg for qemu-devel@nongnu.org; Sun, 07 Aug 2011 14:28:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qq85I-0000zL-4Z for qemu-devel@nongnu.org; Sun, 07 Aug 2011 14:28:24 -0400 Message-ID: <4E3ED941.5080601@redhat.com> Date: Sun, 07 Aug 2011 21:28:17 +0300 From: Ronen Hod MIME-Version: 1.0 References: <20110727152457.GK18528@redhat.com> In-Reply-To: <20110727152457.GK18528@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: Andrea Arcangeli Cc: Jes Sorensen , Luiz Capitulino , qemu-devel@nongnu.org, Michael Roth Well, we want to support Microsoft's VSS, and that requires a guest agent that communicates with all the "writers" (applications), waiting for them to flush their app data in order to generate a consistent app-level snapshot. The VSS platform does most of the work. Still, at the bottom line, the agent's role is only to find the right moment in time. This moment can be relayed back to libvirt, and from there do it according to your suggestion, so that the guest agent does not do the freeze, and it is actually not a mandatory component. Ronen.