From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces
 qcow2 corruptions
Date: Sat, 12 Nov 2011 12:25:34 +0200
Message-ID: <4EBE499E.4030100@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> <4EBCF5DA.1000605@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	Lucas Meneghel Rodrigues <lmr@redhat.com>,
	KVM mailing list <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	QEMU devel <qemu-devel@nongnu.org>,
	Juan Jose Quintela Carreira <quintela@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:65473 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751262Ab1KLKZu (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 12 Nov 2011 05:25:50 -0500
In-Reply-To: <4EBCF5DA.1000605@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 11/11/2011 12:15 PM, Kevin Wolf wrote:
> 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().
>

Intuitively I dislike _reopen style interfaces.  If the second open
yields different results from the first, does it invalidate any
computations in between?

What's wrong with just delaying the open?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.