From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori 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 , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira To: Avi Kivity Return-path: In-Reply-To: <4EBE4869.8060401@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPDfT-0004aQ-DY for qemu-devel@nongnu.org; Sat, 12 Nov 2011 08:30:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPDfS-0000rA-65 for qemu-devel@nongnu.org; Sat, 12 Nov 2011 08:30:47 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:40082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPDfR-0000r5-RE for qemu-devel@nongnu.org; Sat, 12 Nov 2011 08:30:46 -0500 Received: by iakk32 with SMTP id k32so6073969iak.4 for ; Sat, 12 Nov 2011 05:30:45 -0800 (PST) Message-ID: <4EBE7500.2010505@codemonkey.ws> Date: Sat, 12 Nov 2011 07:30:40 -0600 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <4EBE4869.8060401@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira 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