From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: qemu and qemu.git -> Migration + disk stress
 introduces qcow2 corruptions
Date: Wed, 09 Nov 2011 11:35:54 -0600
Message-ID: <4EBAB9FA.3070601@codemonkey.ws>
References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws>
	<4EBAB236.2060409@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>, Kevin Wolf <kwolf@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>
To: Avi Kivity <avi@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <4EBAB236.2060409@redhat.com>
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>
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

On 11/09/2011 11:02 AM, Avi Kivity wrote:
> On 11/09/2011 06:39 PM, Anthony Liguori wrote:
>>
>> Migration with qcow2 is not a supported feature for 1.0.  Migration is
>> only supported with raw images using coherent shared storage[1].
>>
>> [1] NFS is only coherent with close-to-open which right now is not
>> good enough for migration.
>
> Say what?

Due to block format probing, we read at least the first sector of the disk 
during start up.

Strictly going by what NFS guarantees, since we don't open on the destination 
*after* as close on the source, we aren't guaranteed to see what's written by 
the source.

In practice, because of block format probing, unless we're using cache=none, the 
first sector can be out of sync with the source on the destination.  If you use 
cache=none on a Linux client with at least a Linux NFS server, you should be 
relatively safe.

Regards,

Anthony Liguori