From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Date: Sat, 12 Nov 2011 16:36:54 +0200 Message-ID: <4EBE8486.8050102@redhat.com> 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> <4EBE7500.2010505@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Return-path: In-Reply-To: <4EBE7500.2010505@codemonkey.ws> 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 03:30 PM, Anthony Liguori wrote: >> 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? No. > > Let's be very clear. Live migration works perfectly fine when you use > raw images and coherent shared storage. This is not a realistic setup. > > NFS is *not* fully coherent so in order to do live migration with NFS, > you have to use cache=none. While putting restrictions on features is not ideal, requiring cache=none is acceptable as it's that's what's recommended anyway by the qemu management tool writer's guide. > > 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. It must be possible, since RHEL's qemu-kvm supports it. I'm sure Kevin and Juan can make it work. > >> >> 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? > In 2007 when live migration was added, random restrictions like that weren't important. 4.5 years later, pulling support for it makes us look like a joke. Even if it's not technically a regression, in terms of user's expectations, it is. It's simply impossible to delay it for six more months, or however long the 1.1 cycle takes. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPEhZ-0007si-Ua for qemu-devel@nongnu.org; Sat, 12 Nov 2011 09:37:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPEhY-0002Ej-LJ for qemu-devel@nongnu.org; Sat, 12 Nov 2011 09:37:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPEhY-0002Ea-5g for qemu-devel@nongnu.org; Sat, 12 Nov 2011 09:37:00 -0500 Message-ID: <4EBE8486.8050102@redhat.com> Date: Sat, 12 Nov 2011 16:36:54 +0200 From: Avi Kivity 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> <4EBE7500.2010505@codemonkey.ws> In-Reply-To: <4EBE7500.2010505@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira On 11/12/2011 03:30 PM, Anthony Liguori wrote: >> 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? No. > > Let's be very clear. Live migration works perfectly fine when you use > raw images and coherent shared storage. This is not a realistic setup. > > NFS is *not* fully coherent so in order to do live migration with NFS, > you have to use cache=none. While putting restrictions on features is not ideal, requiring cache=none is acceptable as it's that's what's recommended anyway by the qemu management tool writer's guide. > > 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. It must be possible, since RHEL's qemu-kvm supports it. I'm sure Kevin and Juan can make it work. > >> >> 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? > In 2007 when live migration was added, random restrictions like that weren't important. 4.5 years later, pulling support for it makes us look like a joke. Even if it's not technically a regression, in terms of user's expectations, it is. It's simply impossible to delay it for six more months, or however long the 1.1 cycle takes. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.