From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Fri, 11 Nov 2011 15:29:25 +0100 Message-ID: <4EBD3145.3050409@redhat.com> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC1792.3030004@codemonkey.ws> <4EBC4260.1090405@codemonkey.ws> <4EBCF5DA.1000605@redhat.com> <4EBD2B4F.5040409@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucas Meneghel Rodrigues , KVM mailing list , "Michael S. Tsirkin" , "libvir-list@redhat.com" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira , Avi Kivity To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62786 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752678Ab1KKO00 (ORCPT ); Fri, 11 Nov 2011 09:26:26 -0500 In-Reply-To: <4EBD2B4F.5040409@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Am 11.11.2011 15:03, schrieb Anthony Liguori: > On 11/11/2011 04:15 AM, Kevin Wolf wrote: >> Am 10.11.2011 22:30, schrieb Anthony Liguori: >>> Live migration with qcow2 or any other image format is just not going to work >>> right now even with proper clustered storage. I think doing a block level flush >>> cache interface and letting block devices decide how to do it is the best approach. >> >> I would really prefer reusing the existing open/close code. It means >> less (duplicated) code, is existing code that is well tested and doesn't >> make migration much of a special case. > > Just to be clear, reopen only addresses image format migration. It does not > address NFS migration since it doesn't guarantee close-to-open semantics. Yes. But image formats are the only thing that is really completely broken today. For NFS etc. we can tell users to use cache=none/directsync and they will be good. There is no such option that makes image formats safe. > The problem I have with the reopen patches are that they introduce regressions > and change at semantics for a management tool. If you look at the libvirt > workflow with encrypted disks, it would break with the reopen patches. Yes, this is nasty. But on the other hand: Today migration is broken for all qcow2 images, with the reopen it's only broken for encrypted ones. Certainly an improvement, even though there's still a bug left. >> If you want to avoid reopening the file on the OS level, we can reopen >> only the topmost layer (i.e. the format, but not the protocol) for now >> and in 1.1 we can use bdrv_reopen(). > > I don't view not supporting migration with image formats as a regression as it's > never been a feature we've supported. While there might be confusion about > support around NFS, I think it's always been clear that image formats cannot be > used. > > Given that, I don't think this is a candidate for 1.0. Nobody says it's a regression, but it's a bad bug and you're blocking a solution for it for over a year now because the solution isn't perfect enough in your eyes. :-( Kevin