From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCzQc-0004Vf-7u for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:43:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCzQX-0004S6-S4 for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:43:49 -0500 Received: from [199.232.76.173] (port=52166 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCzQX-0004Rl-Ez for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:43:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10040) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCzQW-0003SA-VQ for qemu-devel@nongnu.org; Tue, 24 Nov 2009 12:43:45 -0500 Message-ID: <4B0C1B46.90504@redhat.com> Date: Tue, 24 Nov 2009 18:43:34 +0100 From: Paolo Bonzini MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> <200911241335.35334.paul@codesourcery.com> <20091124134910.GH2405@redhat.com> <200911241359.49321.paul@codesourcery.com> <20091124142152.GN2405@redhat.com> <20091124170809.GC3397@redhat.com> In-Reply-To: <20091124170809.GC3397@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Blue Swirl , Paul Brook , qemu-devel@nongnu.org On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote: >> > 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. We have Juan's VMState work to start from. If we can take it a step further and use anything (including CPP) to make the primary representation of state an XML document or anything like that (and convert it back to VMState structs at build time), it would not be a huge work, and it would give important benefits.