From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: Re: qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Thu, 10 Nov 2011 18:50:49 +0100 Message-ID: References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45906 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751457Ab1KJRwP (ORCPT ); Thu, 10 Nov 2011 12:52:15 -0500 In-Reply-To: <4EBB919B.7040605@redhat.com> (Avi Kivity's message of "Thu, 10 Nov 2011 10:55:55 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > 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. I kind of agree here, but it is not my call. Patch 1/2 have been used on RHEL for almost 3 years, so it should be safe (TM). Later, Juan.