Received: from eggs.gnu.org ([140.186.70.92]:37730)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) 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 <kwolf@redhat.com>) 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 <kwolf@redhat.com>) 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 <kwolf@redhat.com>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>, KVM mailing list <kvm@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "libvir-list@redhat.com" <libvir-list@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, QEMU devel <qemu-devel@nongnu.org>, Juan Jose Quintela Carreira <quintela@redhat.com>, Avi Kivity <avi@redhat.com>

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