From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Thu, 10 Nov 2011 10:55:55 +0200 Message-ID: <4EBB919B.7040605@redhat.com> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29766 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933715Ab1KJI4B (ORCPT ); Thu, 10 Nov 2011 03:56:01 -0500 In-Reply-To: <4EBAB9FA.3070601@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 11/09/2011 07:35 PM, Anthony Liguori wrote: > 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. > IMO, this should be a release blocker. qemu 1.0 only supporting migration on enterprise storage? If we have to delay the release for a month to get it right, we should. Not that I think we have to. -- error compiling committee.c: too many arguments to function