From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcpX-0005Fk-Az for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:57:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDcpV-0006UW-Fx for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:57:15 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:60586) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcpV-0006UG-9A for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:57:13 -0400 Received: by iakl21 with SMTP id l21so7115987iak.4 for ; Tue, 11 Oct 2011 06:57:12 -0700 (PDT) Message-ID: <4E944B35.9070206@codemonkey.ws> Date: Tue, 11 Oct 2011 08:57:09 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E942CFA.5040403@redhat.com> <4E943E21.10501@codemonkey.ws> <4E9442EC.8020903@redhat.com> <4E944440.1080109@codemonkey.ws> <4E944903.4020206@redhat.com> In-Reply-To: <4E944903.4020206@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for October 11th List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, KVM devel mailing list , quintela@redhat.com On 10/11/2011 08:47 AM, Avi Kivity wrote: > On 10/11/2011 03:27 PM, Anthony Liguori wrote: >>> 5) Implement subsections through the wire as top-level sections (as >>> originally intended). Keep existing subsections with (1). >> >> >> That was (3). >> > > Yes, sorry. > >>> btw, it's reasonable to require that backwards migration is only to a >>> fully updated stable release, so we can do 5) too, or backport 1). >> >> But given the choice of a nasty silent failure to an >> not-quite-up-to-date stable release or failing migration to a fully >> up-to-date stable release, I think it's better that we err on the side >> of caution. > > We're erring on the side of no migration, it seems. > >> Not being able to migrate because of a recoverable failure is >> annoying. Having a silent failure that possible results in corruption >> is unacceptable. > > What I'm trying to avoid is making choices today that close the door on > better fixes in the future. I think Juan made a really good point in his earlier post. We need to focus on better testing for migration. With a solid migration torture test, we can probably eliminate much of the problems we're facing today. Regards, Anthony Liguori >