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: Thu, 10 Nov 2011 12:00:48 -0600 Message-ID: <4EBC1150.6030106@codemonkey.ws> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <20111109201836.GA28457@redhat.com> <4EBAE0EA.1030405@codemonkey.ws> <20111109210052.GB28599@redhat.com> <4EBAEA33.9090709@codemonkey.ws> <4EBBAA5C.9010505@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 , Juan Jose Quintela Carreira , Marcelo Tosatti , QEMU devel , "Michael S. Tsirkin" , Avi Kivity To: Kevin Wolf Return-path: Received: from mail-vx0-f174.google.com ([209.85.220.174]:33171 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752161Ab1KJSAw (ORCPT ); Thu, 10 Nov 2011 13:00:52 -0500 Received: by vcbf1 with SMTP id f1so2638843vcb.19 for ; Thu, 10 Nov 2011 10:00:51 -0800 (PST) In-Reply-To: <4EBBAA5C.9010505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/10/2011 04:41 AM, Kevin Wolf wrote: > Am 09.11.2011 22:01, schrieb Anthony Liguori: >> On 11/09/2011 03:00 PM, Michael S. Tsirkin wrote: >>> On Wed, Nov 09, 2011 at 02:22:02PM -0600, Anthony Liguori wrote: >>>> On 11/09/2011 02:18 PM, Michael S. Tsirkin wrote: >>>>> On Wed, Nov 09, 2011 at 11:35:54AM -0600, 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. >>>>> >>>>> A simple solution is not to do any probing before the VM is first >>>>> started on the incoming path. >>>>> >>>>> Any issues with this? >>>>> >>>> >>>> http://mid.gmane.org/1284213896-12705-4-git-send-email-aliguori@us.ibm.com >>>> I think Kevin wanted open to get delayed. >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>> >>> So, this patchset just needs to be revived and polished up? >> >> What I took from the feedback was that Kevin wanted to defer open until the >> device model started. That eliminates the need to reopen or have a invalidation >> callback. >> >> I think it would be good for Kevin to comment here though because I might have >> misunderstood his feedback. > > Your approach was to delay reads, but still keep the image open. I think > I worried that we might have additional reads somewhere that we don't > know about, and this is why I proposed delaying the open as well, so > that any read would always fail. > > I believe just reopening the image is (almost?) as good and it's way > easier to do, so I would be inclined to do that for 1.0. I don't think reopen is good enough without delaying CHS probing too. That information is still potentially out of date. I don't think you can fix this problem without delaying CHS probing at least. Regards, Anthony Liguori > > I'm not 100% sure about cases like iscsi, where reopening doesn't help. > I think delaying the open doesn't help there either if you migrate from > A to B and then back from B to A, you could still get old data. So for > iscsi probably cache=none remains the only safe choice, whatever we do. > > Kevin >