From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5EZw-0004o5-Ue for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:44:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5EZs-0000Kb-QM for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:44:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5EZs-0000KD-Iv for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:44:32 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id DF5B5347A4B for ; Wed, 17 Jun 2015 14:44:31 +0000 (UTC) Date: Wed, 17 Jun 2015 16:44:28 +0200 From: "Michael S. Tsirkin" Message-ID: <20150617163731-mutt-send-email-mst@redhat.com> References: <1434480849-23093-1-git-send-email-dgilbert@redhat.com> <558124BD.8010807@redhat.com> <20150617094829-mutt-send-email-mst@redhat.com> <55812BC4.3000600@redhat.com> <20150617121148-mutt-send-email-mst@redhat.com> <55815B06.5030508@redhat.com> <20150617114053.GG2122@work-vm> <55815D8C.3080904@redhat.com> <20150617120746.GH2122@work-vm> <5581661A.1060101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5581661A.1060101@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: amit.shah@redhat.com, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , quintela@redhat.com On Wed, Jun 17, 2015 at 02:20:42PM +0200, Paolo Bonzini wrote: > > > On 17/06/2015 14:07, Dr. David Alan Gilbert wrote: > > Of course for us on RHEL our minor releases don't correspond to > > QEMU minor releases, so we already support migrating from our > > downstream 7.1 (QEMU 2.1) derivative to our 7.0 (1.5.3) version. > > And the reason for this patch series is to support something >2.2 > > migrating back to that 2.1 (or maybe even to that 1.5.3). > > > > I don't believe we're alone in wanting to be able to do that type > > of thing; > > Others may prefer to have migration only work when it is absolutely sure > that it works. It is much easier to add hacks on top of what upstream > QEMU does (e.g. using the static checker), than to remove the hacks. > > If we really didn't care about others' support for bidirectional > migration, we would have kept the static checker internal to Red Hat. > Or we wouldn't have bothered to refine the .needed functions, and so on. > > Paolo What we need to decide is how major is the breakage. If it's minor - like some lost characters - then it's not worth breaking migration for most users. And I think this should be a property so people can force strict mode if they really want to. If it's a major breakage, it's harder to decide: some people might be able to retry migration later. Maybe a flag to enable this mode would make sense? Also, maybe it would be better to fail migration on source rather than send something destination can't handle? But let's see what the symptoms are before we argue about this option. > > so you can either worry about not burdening upstream > > with compatibility patches like this, or think it's not fair > > to leave them out if others upstream might want them. How many > > others? Well I'd say it's got to be more than some of the other > > obscure features in QEMU!