From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Fri, 11 Nov 2011 08:03:59 -0600 Message-ID: <4EBD2B4F.5040409@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Kevin Wolf Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:33423 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754900Ab1KKOEF (ORCPT ); Fri, 11 Nov 2011 09:04:05 -0500 Received: by iage36 with SMTP id e36so4160601iag.19 for ; Fri, 11 Nov 2011 06:04:04 -0800 (PST) In-Reply-To: <4EBCF5DA.1000605@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. 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. > > 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. Regards, Anthony Liguori > > Kevin >