From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCyuu-0003EV-Vu for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:11:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCyuq-0003Ad-8U for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:11:04 -0500 Received: from [199.232.76.173] (port=47834 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCyup-0003AL-P3 for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:10:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20975) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCyuo-0006u2-RP for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:10:59 -0500 Date: Tue, 24 Nov 2009 19:08:09 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts Message-ID: <20091124170809.GC3397@redhat.com> References: <4B0952C9.9010803@redhat.com> <200911241335.35334.paul@codesourcery.com> <20091124134910.GH2405@redhat.com> <200911241359.49321.paul@codesourcery.com> <20091124142152.GN2405@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Paolo Bonzini , Paul Brook , qemu-devel@nongnu.org On Tue, Nov 24, 2009 at 07:06:01PM +0200, Blue Swirl wrote: > On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin wrote: > > On Tue, Nov 24, 2009 at 01:59:49PM +0000, Paul Brook wrote: > >> > > Reading in old state files is a whole lot easier (to write > >> > > maintain, and stay sane) than producing state that is bug-compatible with > >> > > previous versions. > >> > > >> > It seems to me that old->new and new->old migrations are > >> > of about the same level of difficulty. > >> > Supporting one of these but not the other is of course > >> > easier than supporting both, but I don't see where > >> > "a whole lot" comes from. > >> > >> Migrating from old version requires the restore routine be version aware. > >> Migrating to old versions requires the the save routine also be version aware, > >> which I'd expect to be about double the amount of work. > >> > >> Paul > > > > Heh, it seems the question is whether double is a lot or not :) > > > > The advantage of both save and restore being version aware > > is that you can do light compatibility testing without > > having an old qemu lying around. > > This is not enough, but better than nothing. > > I think the best for us would be if we could make the translator > between versions an external tool with a separate project. > > Supporting only the current version would make QEMU simpler to > maintain, any backward compatibility baggage could be thrown out. > > The external version translator tool could support arbitrary > conversion between the whole NxN matrix of versions (including distro > hacks), or just those that RHEL happens to use. The tool would not be > limited to QEMU development environment, it could use databases, XSLT, > SOA or be written in C#. Yea, maybe cross-hypervisor migration could be made to work :) All that would be possible if the migration protocol would be specified at some level. As it is, the protocol really dumps out internal infromation about current qemu implementation, and it seems that making it a separate project would just slow us down. -- MST