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: Sat, 12 Nov 2011 07:30:40 -0600
Message-ID: <4EBE7500.2010505@codemonkey.ws>
References: <4EBAAA68.10801@redhat.com>	<4EBAACAF.4080407@codemonkey.ws>	<4EBAB236.2060409@redhat.com>	<4EBAB9FA.3070601@codemonkey.ws>
	<4EBB919B.7040605@redhat.com>	<4EBC0FC9.6030301@codemonkey.ws>
	<4EBE4869.8060401@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: <4EBE4869.8060401@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/12/2011 04:20 AM, Avi Kivity wrote:
> On 11/10/2011 07:54 PM, Anthony Liguori wrote:
>>> IMO, this should be a release blocker.  qemu 1.0 only supporting
>>> migration on enterprise storage?
>>
>>
>> No, this is not going to block the release.
>>
>> You can't dump patches on the ML during -rc for an issue that has been
>> understood for well over a year simply because it's release time.
>>
>> If this was so important, it should have been fixed a year ago in the
>> proper way.
>
> Nor can you yank support for migration this way.  Might as well put a
> big sign on 1.0, "Do Not Use This Release".

You're joking, right?

Let's be very clear.  Live migration works perfectly fine when you use raw 
images and coherent shared storage.

NFS is *not* fully coherent so in order to do live migration with NFS, you have 
to use cache=none.

Live migration does not work with image formats.  There's not a simple way to 
make it support image files.  So far, no one has put the work into making it 
support image files.

>
> Making formal plans and sticking to them is great, but not to the point
> of ignoring reality.

Why do you think this is an end of the world feature?

Regards,

Anthony Liguori