From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori 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 , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira To: Avi Kivity Return-path: In-Reply-To: <4EBAB236.2060409@redhat.com> 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROC48-0000Dm-Rb for qemu-devel@nongnu.org; Wed, 09 Nov 2011 12:36:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROC47-0007V5-K2 for qemu-devel@nongnu.org; Wed, 09 Nov 2011 12:36:00 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:56941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROC47-0007Uj-9H for qemu-devel@nongnu.org; Wed, 09 Nov 2011 12:35:59 -0500 Received: by iakk32 with SMTP id k32so2224876iak.4 for ; Wed, 09 Nov 2011 09:35:58 -0800 (PST) Message-ID: <4EBAB9FA.3070601@codemonkey.ws> Date: Wed, 09 Nov 2011 11:35:54 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> In-Reply-To: <4EBAB236.2060409@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira 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