From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Fri, 11 Nov 2011 11:15:54 +0100 Message-ID: <4EBCF5DA.1000605@redhat.com> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC1792.3030004@codemonkey.ws> <4EBC4260.1090405@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucas Meneghel Rodrigues , KVM mailing list , "Michael S. Tsirkin" , "libvir-list@redhat.com" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira , Avi Kivity To: Anthony Liguori Return-path: In-Reply-To: <4EBC4260.1090405@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Am 10.11.2011 22:30, schrieb Anthony Liguori: > Live migration with qcow2 or any other image format is just not going to work > right now even with proper clustered storage. I think doing a block level flush > cache interface and letting block devices decide how to do it is the best approach. I would really prefer reusing the existing open/close code. It means less (duplicated) code, is existing code that is well tested and doesn't make migration much of a special case. If you want to avoid reopening the file on the OS level, we can reopen only the topmost layer (i.e. the format, but not the protocol) for now and in 1.1 we can use bdrv_reopen(). Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROo6R-00081c-Kh for qemu-devel@nongnu.org; Fri, 11 Nov 2011 05:12:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROo6Q-00072X-Qp for qemu-devel@nongnu.org; Fri, 11 Nov 2011 05:12:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROo6Q-00072S-Jm for qemu-devel@nongnu.org; Fri, 11 Nov 2011 05:12:54 -0500 Message-ID: <4EBCF5DA.1000605@redhat.com> Date: Fri, 11 Nov 2011 11:15:54 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC1792.3030004@codemonkey.ws> <4EBC4260.1090405@codemonkey.ws> In-Reply-To: <4EBC4260.1090405@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Lucas Meneghel Rodrigues , KVM mailing list , "Michael S. Tsirkin" , "libvir-list@redhat.com" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira , Avi Kivity Am 10.11.2011 22:30, schrieb Anthony Liguori: > Live migration with qcow2 or any other image format is just not going to work > right now even with proper clustered storage. I think doing a block level flush > cache interface and letting block devices decide how to do it is the best approach. I would really prefer reusing the existing open/close code. It means less (duplicated) code, is existing code that is well tested and doesn't make migration much of a special case. If you want to avoid reopening the file on the OS level, we can reopen only the topmost layer (i.e. the format, but not the protocol) for now and in 1.1 we can use bdrv_reopen(). Kevin